How to Connect Git Version Control to Deploy Repositories in StackCP

If you or your developer work with Git for version-controlled website development, StackCP includes a built-in Git integration that lets you clone, manage, and deploy repositories directly from your browser — no SSH or command line required. This guide walks through connecting a GitHub repository and deploying changes, as well as setting up a local repository if you'd rather not rely on a remote one.

What Does Git Version Control in StackCP Actually Do?

Git is fully integrated into StackCP's dashboard, meaning creating repositories, deploying changes, or reverting to earlier versions can all be done through the browser interface. You can manage multiple repositories within a single hosting package, keeping track of version history and deploying updates to your live site whenever you're ready.

Step 1: Enable Git for Your Hosting Package

1. Log in to StackCP.
2. Go to Manage Hosting, then select Options > Manage on the package you want to set up.
3. Under Web Files, select Git™ Version Control.
4. The first time, you'll be prompted to either sign in via GitHub single sign-on, or enter your details manually — providing a name and email address, which will be shown when deploying using Git.
5. Select Enable.

You'll land on your repository list — empty if this is your first time — along with the option to set up your first repository.

Step 2: Clone a Remote Repository from GitHub

1. Before cloning, make sure you already have a remote repository set up on GitHub (following GitHub's own documentation if you haven't done this before).
2. In your GitHub repository, select Code, then copy the provided URL.
   • For a public repository, the standard HTTPS URL works directly.
   • For a private repository, you'll need to set up a public/private SSH key pair first, and use the SSH URL instead.
3. Back in StackCP, paste the URL into the Clone URL field.
4. Set the file path — where in your hosting account you want the repository's files to live.
5. Set a Repository Name — a display name shown in the StackCP interface (this doesn't need to match the GitHub repository name exactly).
6. Select Create.

Your repository will now appear in your Repository List, along with its configured path.

Step 3: Managing a Repository

Each repository in your list has a "kebab" menu (three vertical dots) offering:

• Manage — the main screen for pulling and deploying changes.
• History — a log of what's been deployed over time.
• File Manager — jump directly to the repository's files.
• Copy URL — copy the clone URL for reference.
• Remove — remove the repository from StackCP (this doesn't delete your remote GitHub repository itself).

Step 4: Pulling and Deploying Changes

1. From the repository's Manage screen, go to the Development tab (previously labelled "Pull or Deploy" in earlier versions of the interface).
2. Select Deploy HEAD Commit to deploy the latest changes from your repository to your live hosting files.
3. Use the History tab afterward to confirm what was deployed and when.

Step 5: Setting Up a Local Repository (No Remote Needed)

If you'd rather work with a repository that lives entirely within your hosting package's file space, rather than syncing with a remote GitHub repository:

1. From your repository list, select Create New Repository.
2. Choose the Local Repository tab.
3. Fill in the folder you want the repository to use, a name, and choose your Deployment Type:
   • Automatic — changes deploy as soon as they're committed.
   • Manual — changes only deploy when you specifically select Deploy.
4. Choose your Deployment Branch — the specific Git branch whose changes should be deployed.

A Note on Git Hooks (Advanced)

If you or your developer want to use Git hooks (scripts that run automatically at specific points in the Git workflow, like after a push), StackCP requires a small configuration change pointing your repository to its own hook path, rather than the default. This is a security measure ensuring hooks can only run in languages supported on the platform. This is an advanced, optional setup — most beginners using the standard clone-and-deploy workflow described above won't need to touch this.

Common Mistakes Beginners Make

• Trying to clone a private repository using the standard HTTPS URL. Private repositories require setting up an SSH key pair first and using the SSH clone URL instead.
• Expecting changes to deploy automatically after every commit, when the repository is actually configured for manual deployment. Check your Deployment Type setting if this catches you out.
• Confusing "Remove" with deleting the actual GitHub repository. Removing a repository from StackCP's list only disconnects it from your hosting package — your remote repository on GitHub remains untouched.
• Not checking the History tab after a deployment, missing a useful record of exactly what changed and when.

Troubleshooting

"I can't clone my private repository." Confirm you've set up a public/private SSH key pair and are using the SSH clone URL from GitHub, not the standard HTTPS URL, which only works for public repositories.

"My changes aren't showing up on my live site after a commit." Check whether your repository is set to automatic or manual deployment. If manual, you'll need to select Deploy HEAD Commit yourself after each set of changes.

"I want to undo a deployment." Use the History tab to review previous deployments, and consider deploying an earlier commit if you need to roll back — Git's version history is exactly what makes this possible.

A Practical Workflow Example

To make this concrete, here's how a typical developer workflow might look using StackCP's Git integration for an agency client site:

1. The developer builds and tests the site locally, committing changes to a GitHub repository as they go.
2. Once ready to deploy, they clone that GitHub repository into the client's StackCP hosting package, setting the file path to the site's web root.
3. For ongoing updates, rather than re-cloning each time, they simply push new commits to GitHub, then return to StackCP's Development tab and select Deploy HEAD Commit to bring those changes live.
4. If something goes wrong after a deployment, the History tab provides a clear record of exactly what was deployed and when, making it easier to identify which change might be responsible.

This workflow removes the need for manual FTP uploads of changed files, reducing both the effort and the risk of accidentally missing a file during a manual transfer.

Why This Matters for a White-Label Hosting Business

If you're offering hosting to customers who work with developers or agencies, having genuine Git deployment support built into the same panel your customers already use is a meaningful capability to highlight — it means their development workflow doesn't need to sit outside the hosting environment entirely, and they're not limited to manual file uploads for every update. For customers less familiar with Git themselves, it's enough to know the capability exists and can be handed to a developer they bring in, without needing to understand the full workflow personally.

Local vs Remote Repositories: Which Should You Choose?

If you're deciding between setting up a remote (GitHub-synced) repository versus a local one, it's worth thinking about your actual workflow needs. A remote repository makes sense if you're collaborating with others, want an off-site backup of your code history, or are already using GitHub as part of a broader development process. A local repository makes sense if your main interest is simply having Git's version tracking and controlled deployment (choosing exactly when changes go live) without needing to sync anywhere external — useful, for instance, if a single developer is making direct edits through the File Manager or SSH but still wants a safety net of version history and the ability to roll back a specific commit if something breaks.