Git deployment: automatically deploy your website with version control
Manually uploading files via FTP is a workflow from a different era. It's slow, error-prone, and offers no version control. Git deployment modernizes this process: you push your code and changes automatically go live. In this comprehensive guide I explain how to set up Git deployment and get the most out of it.
Why switch from FTP to Git deployment?
The traditional workflow for many developers and website owners is simple but problematic. You edit files locally, open an FTP client, navigate to the right folder on the server, upload the changed files, and hope everything works. This workflow has fundamental problems.
It's easy to forget files. You change five files, upload four, and wonder why the site isn't working. It's also easy to upload the wrong version. You test locally, forget to save, upload an old version, and don't see the changes. There's no history of what you changed and when. If something breaks, you can't easily go back to a working version.
Git deployment solves all these problems. Git tracks which files have changed, so you miss nothing. Every change is a commit with a description, so you know exactly what you did and when. The full history is available to go back to if needed. And the deployment process is consistent and repeatable.
What are the different approaches to Git deployment?
Git push to a server remote
The most direct method is configuring a Git remote on your production server. You push to this remote, and a hook ensures the changes are applied to your website directory. This requires SSH access to your server and some configuration, but is simple to use afterward.
CI/CD pipelines
Continuous Integration and Continuous Deployment pipelines offer more control and flexibility. Platforms such as GitHub Actions, GitLab CI, or Bitbucket Pipelines detect when you push code to your repository. They then run a defined series of steps: running tests, building assets, and finally deploying to your server.
This approach is more powerful than a simple git push. You can automatically run tests before code goes live. You can add build steps for frontend assets. You can deploy to multiple environments. But it requires more setup and knowledge of CI/CD concepts.
Hosting with built-in Git integration
Some hosting providers build Git deployment directly into their platform. You connect your GitHub or GitLab repository and every push to a specific branch automatically triggers deployment. Cloudways, Kinsta, Vercel, and Netlify are examples. This is the easiest option if your hosting supports it.
Deployment tools
Tools such as Deployer for PHP, Capistrano for Ruby, or Envoy for Laravel offer advanced deployment functionality. You define deployment tasks in configuration files and the tool executes them. This is valuable for complex deployments with multiple steps, but overkill for simple sites.
Setting up Git deployment on a VPS step by step
Step one: install Git on the server
Log in to your server via SSH. Install Git if it's not already present. On Ubuntu or Debian you do this with apt update followed by apt install git. On CentOS or RHEL you use yum install git. Verify the installation with git version.
Step two: create a bare repository
Create a directory for your Git repository, for example /var/repo/mysite.git. Navigate to this directory and initialize a bare repository with git init bare. A bare repository contains only Git data, no working directory with files. It's purely for receiving pushes.
Step three: configure the post-receive hook
The magic is in the post-receive hook. This is a script Git runs after receiving a push. Create the file hooks/post-receive in your bare repository. This script needs to check out the code to your website directory.
A basic script defines variables for your target directory and repository location. It reads the received references and checks whether it's the right branch. If so, it checks out the code to the target directory. Make the script executable with chmod plus x.
Step four: add the remote to your local repository
In your local project, add a new remote pointing to your server. Use git remote add production with the SSH address of your repository. You can give the remote any name you like; production is descriptive of where the code is going.
Step five: deploying
Now you can deploy with a simple command: git push production main. Git pushes your commits to the server, the post-receive hook runs, and your code appears in the website directory. Every subsequent push works the same way.
Automating deployment with GitHub Actions
GitHub Actions offers a powerful way to automate deployment. You create a workflow file in your repository under .github/workflows. This YAML file defines when the workflow runs and which steps are executed.
A basic deployment workflow triggers on pushes to the main branch. The job runs on an Ubuntu runner, checks out the code, and connects via SSH to your server to run a git pull. You configure the SSH credentials as secrets in your GitHub repository settings so they stay secure.
The advantage of GitHub Actions over a direct git push is that you can add extra steps. Run tests first to make sure the code works. Build frontend assets with npm or webpack. Send a notification to Slack when deployment succeeds or fails. The possibilities are extensive.
Best practices for safe and reliable Git deployment
Keep credentials out of your repository
This is crucial and non-negotiable. Passwords, API keys, database credentials, and other secrets don't belong in your Git repository. Even if your repository is private, this is a risk. Use environment variables configured on the server, or a secrets manager. Add sensitive files to your .gitignore.
Test before you deploy
With CI/CD you can automatically run tests before code goes live. If tests fail, the deployment doesn't proceed. This catches bugs before they reach production. Even without automated tests, it's wise to test locally before pushing.
Use a staging environment
Don't deploy directly to production. Have a staging environment that resembles production as closely as possible. Deploy there first, test manually or automatically, and only then deploy to production. This adds a layer of safety.
Consider atomic deployments
Advanced deployment setups deploy to a new directory and then switch a symlink to the new version. If something goes wrong, you can go straight back to the previous version by switching the symlink back. The old version stays intact. Tools such as Deployer support this pattern.
Have a rollback strategy
Know how to go back to a previous version if something goes wrong. With Git this is technically simple: you can revert a commit or reset to an earlier state. But practice this before you need it in a crisis. Know the commands and how they work.
Specific considerations for WordPress and Git
WordPress requires extra attention with Git deployment. The wp-config.php file contains database credentials and doesn't belong in your repository. Add it to .gitignore and manage it separately on the server. The uploads directory contains user-uploaded media and also doesn't belong in Git. Use .gitignore and manage media separately or via a CDN.
The database itself contains content and settings that don't go through Git. Database migrations are more complex than file deployment. Consider a tool like WP Migrate or a workflow with database exports.
Bedrock is a modern WordPress stack that works better with Git. It structures WordPress as a dependency and separates configuration from code. If you're serious about WordPress with Git, Bedrock is worth investigating.
Common mistakes and how to avoid them
A common mistake is deploying without testing. It works locally, so it'll surely work in production, right? No. Environment differences, missing dependencies, and configuration differences can cause problems. Always test.
Committing credentials is another mistake with serious consequences. Even if you remove it later, it stays in the Git history. Use git-secrets or similar tools to prevent accidentally committing secrets.
No monitoring after deployment is also risky. You deploy and assume everything works. But actually check whether the site is running and whether critical functions work. Automate this where possible.
Git deployment transforms how you manage websites. The initial setup takes time, but the benefits in speed, reliability, and traceability make it more than worthwhile. Start simple with a basic git push setup and expand to CI/CD as your needs grow.
Git deployment checklist and best practices
A successful git deployment requires a structured approach. Use the checklist below to make sure every git deployment goes smoothly.
- Check that all changes are committed before the git deployment
- Run tests locally before starting a git deployment
- Use feature branches and only merge to main after review
- Configure automatic git deployment via CI/CD pipelines
- Keep a rollback strategy ready for every git deployment
- Document every git deployment in a changelog
| Git deployment method | Complexity | Suitable for |
|---|---|---|
| Manual git pull | Low | Small projects |
| Git hooks (post-receive) | Medium | Single server |
| CI/CD (GitHub Actions) | Medium-High | Teams and professional projects |
| Kubernetes + GitOps | High | Enterprise and microservices |
Whether you host a simple website on a VPS or manage a complex application, git deployment keeps managing your code organized and reliable. Combine git deployment with a good hosting environment for the best results.
How do you set up git deployment: CI/CD pipelines?
The next step after manual git deployment is setting up an automated CI/CD pipeline (Continuous Integration/Continuous Deployment). This automatically tests and deploys your code as soon as you push changes to your repository.
GitHub Actions for deployment
GitHub Actions is a popular choice for automated deployment. You define workflows in YAML files that run on every push. A typical deployment workflow includes the following steps:
- Fetch code from the repository
- Install dependencies (npm install, composer install)
- Run tests (unit tests, integration tests)
- Build assets (compile CSS, JavaScript)
- Deploy to the production server via SSH or rsync
GitLab CI/CD as an alternative
GitLab offers an integrated CI/CD solution that's particularly powerful. The pipeline is defined in a .gitlab-ci.yml file in the root of your repository. GitLab also supports environments, review apps, and auto-deploy to Kubernetes clusters.
How do you compare git deployment strategies?
There are several strategies for git deployment, each with its own pros and cons.
| Strategy | Downtime | Complexity | Rollback | Suitable for |
|---|---|---|---|---|
| Direct deployment | Short | Low | Git revert | Small projects |
| Blue-green deployment | None | Medium | Instant (switch) | Production environments |
| Rolling deployment | None | High | Gradual | Multiple servers |
| Canary deployment | None | High | Fast | Large applications |
Blue-green deployment explained
With blue-green deployment you run two identical production environments: "blue" (current version) and "green" (new version). You deploy the new code to the green environment, test it thoroughly, and then switch traffic from blue to green. If problems arise, you switch back immediately.
Best practices for git deployment
To keep your git deployment process reliable and secure, follow these best practices:
- Use feature branches - Develop new functionality on separate branches and only merge to main once everything is tested
- Automate tests - Never let code deploy that hasn't passed all tests
- Configuration outside the repository - Store passwords, API keys, and other sensitive data in environment variables, not in your code
- Run database migrations separately - Run migrations before deploying the new code to prevent compatibility issues
- Monitoring after deployment - Set up uptime monitoring to detect problems immediately after deployment
- Document your deployment process - Make sure every team member can carry it out, not just the lead developer
With a well-set-up git deployment process you save hours per week of manual work and minimize the chance of mistakes when putting changes on your website live.
Git deployment: avoiding common mistakes
When setting up git deployment, the same mistakes come up again and again, leading to problems when putting changes live. Know these pitfalls and prevent them.
The most common mistake is committing sensitive information to the repository. Passwords, API keys, and database credentials don't belong in your codebase. Use a .gitignore file to exclude configuration files and store sensitive data in environment variables. If you accidentally committed secrets, removing them in a new commit is not enough: they're still in the Git history. Use tools like git-filter-repo to rewrite the history.
Another common mistake is deploying directly to production without using a staging environment. Always test your changes first on an environment identical to production. This prevents bugs, conflicts, or configuration issues from being discovered only on the live server. Automate this process by setting up your CI/CD pipeline so changes are deployed to staging first.
Also don't forget to make your deployment scripts idempotent. This means the script produces the same result no matter how many times you run it. If a deployment fails halfway and you run it again, this shouldn't cause problems. Use conditional checks and transactions in your migration scripts to guarantee this. With good migration practices and automated tests, you build a robust deployment system that gives your team confidence with every release.
Git deployment: getting started with your first pipeline
If you have no experience yet with automated git deployment, start with a simple setup you can gradually expand. The easiest way to start is with a post-receive hook on your production server. This is a script that runs automatically when you push code to the server. The script pulls the latest code and restarts the web server if needed.
A step further is setting up a GitHub Actions workflow. Create a file in your repository at the path .github/workflows/deploy.yml. Define the steps that should run on every push to the main branch: fetching code, running tests, and deploying via SSH. GitHub offers generous free minutes for public and private repositories, so you can get started without extra costs. Start simple and gradually add more steps as your confidence grows. A CI/CD pipeline is never finished: it evolves along with your project and becomes more reliable as you add more tests and checks to the process.
Git deployment: conclusion and next steps
With a well-set-up git deployment system you take your development workflow to a professional level. The benefits are unmistakable: every change is traceable, rolling back is easy, and collaborating with multiple developers runs conflict-free. Start simple with a basic workflow that automatically deploys to your production server on every push to main. Gradually add more steps: automated tests, linting, security scans, and notifications. Document your deployment process so every team member can carry it out and understand it. Invest in a staging environment to test changes before they go live. With these building blocks you create a reliable, repeatable deployment process that gives you confidence with every release and minimizes the chance of human error.
Git deployment best practices for teams
When working with git deployment in a team setting, there are additional best practices that make the process run more smoothly. Use branch protection rules to prevent anyone from pushing directly to main without code review. Require pull request reviews so at least one team member approves every change before it's merged. Use conventional commit messages with a fixed format so the history stays readable and changelogs can be generated automatically. Implement automatic rollbacks that restore the previous version if a deployment fails or if monitoring detects that the new version is causing errors. Keep your branches short: feature branches that exist longer than a week become hard to merge and cause conflicts. With these practices you build a robust deployment pipeline that has the trust of the whole team.
