Updating a website with git pull: simple, reliable deploys on hosting

On small and medium sites, deploying often means copying files over FTP by hand. It works, but people forget which files changed, stale files pile up on the server and two developers can overwrite each other's work. If the project already lives in Git, the server can be treated as just another clone of the repository. Updating then becomes a single git pull, and the code on the server always matches a specific commit.

When this approach fits

Pull-based deploys suit plain PHP sites, WordPress themes and plugins, Laravel projects and static pages. You need SSH access and git on the server; whether SSH is included in your sayt.uz hosting plan can be checked in the cabinet or with support, and on a VPS you install Git yourself. Keep in mind that each pull creates a few seconds where some files are new and some are old. For busy shops, a release-folder and symlink setup avoids that.

A read-only deploy key

For a private repository the server needs its own key. Never store your personal GitHub password on a server; add a read-only deploy key instead.

ssh-keygen -t ed25519 -C "deploy@example.uz" -f ~/.ssh/deploy_key -N ""
cat ~/.ssh/deploy_key.pub   # add this line under the repository's Deploy keys

# ~/.ssh/config
Host github.com
    IdentityFile ~/.ssh/deploy_key
    IdentitiesOnly yes

Test it with ssh -T git@github.com. Because the key is read-only, an attacker who compromises the server still cannot push code to your repository.

First clone and the .git folder

Hosting accounts usually have a fixed web root such as ~/www/example.uz. Back up anything already there, empty the folder and clone into it.

cd ~/www
git clone git@github.com:misol/example-sayt.git example.uz
cd example.uz && git log --oneline -1

The .git directory in the web root contains the whole project history, sometimes including old passwords. If the web server serves it, anyone can download your code, so block it explicitly, or better, point the web root at a subfolder such as public.

# .htaccess (Apache)
RedirectMatch 404 /\.git

# Nginx
location ~ /\.git { deny all; return 404; }

.gitignore for server-only files

.env, wp-config.php, user uploads and caches must stay out of the repository, otherwise a pull overwrites them or production secrets end up on GitHub.

.env
wp-config.php
storage/logs/
wp-content/uploads/
vendor/
node_modules/

An update script

This Laravel example refuses to run if someone edited tracked files on the server and only performs fast-forward updates, so it never tries to merge diverged history.

#!/bin/bash
set -e
cd ~/www/example.uz
if [ -n "$(git status --porcelain --untracked-files=no)" ]; then
  echo "Uncommitted changes on server, aborting"; exit 1
fi
git fetch origin
git pull --ff-only origin main
composer install --no-dev --optimize-autoloader
php artisan migrate --force
php artisan config:cache
echo "Deployed: $(git log --oneline -1)"

Save it as deploy.sh and run chmod +x deploy.sh. For a WordPress theme, git pull plus a cache flush is usually enough.

Example: a training centre in Samarkand

A Samarkand training centre has a plain PHP site with a course timetable and a sign-up form. Its developer once uploaded an old version of the form file over FTP and no applications arrived for a whole day. Now he commits on his laptop, pushes to GitHub and runs ./deploy.sh on the server. If something breaks, he finds the previous commit in git log and restores it within a minute.

Common errors

"Your local changes would be overwritten by merge" means someone edited files directly on the server; inspect them with git diff and either move them into the repository or discard them with git checkout -- file. "Permission denied (publickey)" points to a missing deploy key or a wrong config entry. If the clone was made as root, the site may be unable to save uploads, so always run Git as the user that owns the site.