Git basics for deploying your site

Why is Git Essential for Website Deployment?

If you're still uploading website files via FTP or a file manager panel, you're probably familiar with this scenario: a small change in the code, a missed file, and the site goes down. Git turns this chaos into a traceable and reversible process. With Git, every code change gets a "commit" with a clear message and a unique identifier; if something breaks, you can revert exactly to the previous version.

In this tutorial, we assume you're familiar with Git basics and want to use it to deploy a website on a Linux server (such as Ubuntu or Debian). The ultimate goal is to deploy the latest version of the site with a single git pull command on the server, without manually uploading files.

Recommended Repository Structure for Deployment

First of all, you need to decide what structure your Git repository should have. For a simple website, the entire project is usually kept in one repository. But if you have multiple separate services (like frontend, backend, and config), it's better to have a separate repository for each.

Take .gitignore Seriously

The first step is to create a .gitignore file at the project root. This file determines which files should not be included in the repository. For a PHP or Node.js site, you typically ignore the following:

# Dependencies
/vendor/
/node_modules/

# Environment files
.env
.env.local

# Log files
*.log

# Temporary files
/tmp/
/cache/

Important note: The .env file contains database passwords and API keys. If you commit it to the repository, your site's security is at risk. On the server, create this file separately and manually.

Setting Up the Repository on the Server

To deploy with git pull, you first need to clone the repository on the server. There are two scenarios: private repository or public repository. If the repository is private, you need to set up an SSH key on the server.

Creating an SSH Key on the Server

Log in to the server and run the following command:

ssh-keygen -t ed25519 -C "deploy@yourserver"

Display the public key with the following command and add it to the repository settings (like GitHub or GitLab) under Deploy Keys:

cat ~/.ssh/id_ed25519.pub

Now clone the repository to your desired path. For example, for a site located at /var/www/mysite:

cd /var/www
git clone git@github.com:username/mysite.git

If the repository is public, you can use HTTPS, but SSH is more secure and better suited for automated deployment.

Deployment Workflow with Branches

One of the most common mistakes is deploying directly from the main or master branch. This is risky because any incomplete commit is immediately applied to the live site. It's better to use a dedicated deployment branch.

Recommended Branch: production

Create a separate branch called production that only receives stable versions. The workflow looks like this:

1. The developer works on the develop branch and commits changes.
2. After testing, the develop branch is merged into production.
3. On the server, you only pull from the production branch.

On the server, switch the active branch:

cd /var/www/mysite
git checkout production

Now, whenever you want to deploy a new version, all you need to do is:

git pull origin production

This command applies the latest changes from the production branch to the server. If a file has been manually changed on the server and conflicts with the repository, Git will throw an error and ask you to resolve the issue.

Handling Common git pull Errors

During deployment, you may encounter errors. Here, we'll look at two common cases.

"local changes would be overwritten" Error

This error occurs when a file has been manually changed on the server and conflicts with new repository changes. The safe solution is to stash your local changes:

git stash
git pull origin production
git stash pop

If the manual changes are no longer needed, you can discard them:

git checkout -- .
git pull origin production

Note: The second command removes all local changes. Only use it when you're sure nothing important will be lost.

"Permission denied" Error During Clone

If you're using SSH and see this error, you probably haven't added the public key correctly. Make sure you've added the key to the repository's Deploy Keys section and granted it read access. You can also test the connection:

ssh -T git@github.com

If you receive a success message, the issue is with the repository settings.

Automating Deployment with Webhooks

If you don't want to manually log in to the server and run git pull every time, you can use a Webhook. A Webhook is an HTTP URL that the repository hosting service (like GitHub) sends a request to when a push occurs.

Simple Script for Automated Deployment

Create a simple PHP file on the server that runs the pull command. For example, at /var/www/mysite/deploy.php:

<?php
// Only allow specific IPs
$allowed_ips = ['192.30.252.0/22'];
$ip = $_SERVER['REMOTE_ADDR'];

// Run the pull command
$output = shell_exec('cd /var/www/mysite && git pull origin production 2>&1');
echo "<pre>{$output}</pre>";
?>

Then, in the repository settings, add a Webhook pointing to https://yoursite.com/deploy.php. Now, every time you push to the production branch, the server will automatically pull the latest version.

Security warning: Don't leave this script without IP restrictions. Anyone who knows the URL could trigger a pull. At minimum, add a secret token:

<?php
if ($_GET['token'] !== 'YOUR_SECRET_TOKEN') {
    http_response_code(403);
    exit('Forbidden');
}
// Rest of the script
?>

And in the Webhook settings, add the token as a parameter.

Rolling Back to a Previous Version

The most important advantage of Git in deployment is the ability to quickly roll back. If the new version has issues, you can revert to a previous commit. There are two methods:

Method 1: git revert

This method creates a new commit that undoes the changes of the problematic commit. The repository history remains intact:

git log --oneline -5
git revert HEAD

Then push the changes and pull on the server.

Method 2: git reset

This method rewrites history and is suitable for situations where you haven't pushed yet. If you've already pushed, don't use this method because it corrupts the repository history for others:

git reset --hard HEAD~1

On the server, if you want to revert to a specific commit:

git checkout <commit-hash> -- .

This command restores files to the state of that commit, but doesn't change the branch.

Final Tips for Professional Deployment

To make the Git deployment process truly professional, follow these tips:

• Always back up the database before pulling. Git only manages code, not data.
• After pulling, if the site uses Composer or npm, update dependencies: composer install --no-dev or npm ci --production.
• Don't keep user-uploaded files (like images) in the repository. Place them in a separate path like /var/www/mysite/uploads and ignore them in .gitignore.
• For large sites, deploy to a test server first, then to the production server. Git makes this easy: just pull the same branch on both servers.

If you're looking for infrastructure that runs this process smoothly, ServerNet's web hosting and cloud server services could be a good option; but the final decision is yours, and this tutorial can be implemented independently of any service.

With this approach, website deployment is no longer a high-risk operation; it's a predictable, testable, and reversible process. Just set up this workflow once and enjoy the peace of mind it brings.