Git manager: repositories without leaving SHM
Use SHM Git Manager to clone, initialise and maintain account-owned repositories, branches, remotes, commits and deployment workflows safely.
Clone, initialise, inspect and maintain account-owned Git repositories with branches, remotes, commits and visible command output in one workspace.
A repository workflow should be documented, repeatable, and available from the same account context as the deployed project. Git Manager brings the common repository workflow into the SHM account while keeping every path inside that account's home.
You can initialise a repository in an existing project or clone one from GitHub, GitLab, Bitbucket, or another Git server. SHM validates the destination and works with the repository in place, avoiding unnecessary copies through a temporary deployment directory.
Branches and remotes, together
The repository view exposes the details that matter during routine work: current status, local and remote branches, configured remotes, and the output from the latest action. Fetch, pull, push, checkout, commit, and remote management are available without flattening Git into a single optimistic "sync" button.
That distinction matters. A pull can conflict. A push can be rejected. A branch can be behind for a perfectly valid reason. SHM shows the real command result so the user can act on the repository state and any reported conflict or rejection.
Decide how credentials enter
Private repositories need authentication. Git Manager supports the normal Git access patterns, including HTTPS credentials and SSH keys. SSH keys are the cleaner choice for long-lived automation because they can be scoped and rotated without embedding a reusable password in a remote URL.
Where HTTPS credentials are used, SHM follows the account user's Git configuration and credential workflow. The panel does not turn a repository credential into server-root authority, and one account cannot point Git Manager at another account's files.
Keep the real output
Repository operations can take time, especially for a large first clone or a remote with a lively history. Git Manager streams useful output into the workspace so users can see whether Git is resolving objects, waiting on authentication, or reporting a conflict. The browser can stop following that output, while the result remains the result produced by Git.
The useful information is what Git did, which branch it affected, and what needs attention next. Git Manager keeps that output visible throughout the operation.
A repository tool within the deployment process
Git Manager does not force one deployment philosophy. It works for a small site whose owner pulls reviewed changes, a Node.js application that builds after an update, or a team that keeps production and development branches separate. Runtime restarts and application-specific build commands remain deliberate steps, because build and restart behavior must remain explicit for the selected application.
By keeping repositories, paths, credentials, and output in the account context, SHM makes Git accessible to less experienced users without hiding the mechanics experienced users need. The repository stays a real Git repository, which means the workflow remains portable outside the panel too.