Deploy a Website with Git

Git deploy vs FTP

FTP versus Git deployment is really manual-versus-reproducible — FTP drags changed files by hand and forgets what it did; Git replays a known state. Pattern one, push-to-deploy on your own server (VPS or hosting with SSH):

1. On the server: git init --bare the deploy repo in a non-webroot path.
2. Add a post-receive hook that checks out the tree to the webroot (git --work-tree=/home/USER/public_html --git-dir=/home/USER/repo checkout -f) and runs any build or permission fixups.
3. Locally: git remote add deploy user@server:repo, then git push deploy main — every push deploys.

Pattern two, GitHub Actions, suits anything with a build step (React, Vue, Astro, Vite): the workflow builds, then rsyncs or SFTP-syncs the artifacts to the server.

Method 1: post-receive hook setup

Two practical notes on git push deployment: it interacts directly with caching and database response, and misconfiguration is the most common cause of 'hosting is slow' tickets. WebJi® support checks it as part of standard migrations.

Method 2: GitHub Actions workflow

Two practical notes on post-receive hooks: it interacts directly with caching and database response, and misconfiguration is the most common cause of 'hosting is slow' tickets. WebJi® support checks it as part of standard migrations.

Deploying built sites to public_html

Deploying built sites to public_html. Do the change this heading names on one site first, then check it in a private browser window or in the mail client, depending on the topic. Change one setting at a time, and undo it if the result is wrong before you try the next. If you want the Jaipur desk to look with you, email support@webji.services — that mailbox is staffed 24/7 in Hindi and English. Phone +91 141 4941811 is business hours only.

Fixing permission denied errors

Permission denied errors decode by layer:

• git push deploy permission denied (publickey) — the pushing machine's key is not in the server user's authorized_keys; fix with ssh-copy-id user@server, then test with ssh -T before blaming Git.

• Hook runs but files unchanged — the post-receive lacks the executable bit (chmod +x), or the work-tree path is wrong (absolute paths prevent this).

• rsync/Actions failures writing public_html — the SSH user does not own the directory; chown -R user:user /var/www/html, or use the cPanel account's own home (/home/USER/public_html), where the account always owns its files.

• Hooks writing as root — keep one deploy user throughout; directories 755, files 644.

gitignore essentials

gitignore essentials. Do the change this heading names on one site first, then check it in a private browser window or in the mail client, depending on the topic. Change one setting at a time, and undo it if the result is wrong before you try the next. If you want the Jaipur desk to look with you, email support@webji.services — that mailbox is staffed 24/7 in Hindi and English. Phone +91 141 4941811 is business hours only.

Rolling back safely

Rollback discipline is why Git beats FTP. Hook pattern. The repo has every prior release, so SSH in and run the checkout command against the previous hash (git --work-tree=... --git-dir=... checkout -f <old-hash>), or locally git revert the bad commit and push again.

Actions pattern: keep releases immutable — an advanced setup deploys to timestamped releases/ directories with a symlink switch, making rollback a one-line symlink flip and eliminating half-deployed states. Simpler repos just re-run the workflow from the older commit (GitHub allows running a workflow at a ref). Whatever the mechanism, rehearse a rollback once before you need it at 2 am, and keep a tag named stable pinned to the last-known-good release.