Performance Glossary
Git: Deployments You Can Undo in One Command
Production broke on a Friday release and your recovery plan is comparing FTP timestamps to work out which files you changed.
The short answer
Git records every change to a codebase as a sequence of commits, which makes deployment one pull and recovery from a bad release one checkout — seconds, not an archaeology session across file timestamps.
It covers code and configuration only. Your database and your uploads are outside it entirely, which is why Git and backups solve different problems and neither substitutes for the other.
By the HostingFast team · Reviewed 12 August 2026
100+
Terms, measured not asserted
2 min
To read one entry
Plain
Commands you can run
24/7
Engineers on shift
A commit freezes the project under a name you choose, branches keep two pieces of work from tangling, and restoring any previous state is a single command. Keeping a clone on the server converts 'upload the files I think changed' into a repeatable operation.
From a hosting perspective, Git sitting alongside SSH is the signal that a plan was built with developers in mind. Push-to-deploy and instant rollback are not exotic; they simply require a shell, and plenty of plans do not offer one.
What rollback actually costs
git checkout of the previous tag puts the working tree back to a known-good state in the time it takes to write out the files. Compare that with restoring a full backup, which moves the database too and therefore undoes every order and comment that arrived since.
That difference is the reason to deploy this way even as a team of one. Code problems get a code-shaped fix, and the state your visitors created stays untouched while you sort it out.
Keeping the repository out of the web root
A .git directory served over HTTP hands an attacker your entire history, including any credential ever committed and later removed. Check it with curl against /.git/HEAD — a 200 there is an emergency, and a 403 or 404 is what you want to see.
The clean pattern is a bare repository outside the document root with a post-receive hook that checks the working tree out into place. Where that is not available, deny access to .git in .htaccess and verify with the same curl before you move on.
What belongs in the repository
Code, templates and configuration templates go in. Secrets, uploads and vendor directories stay out — secrets because history is forever, uploads because they are user data rather than code, and vendor because Composer can rebuild it deterministically from the lock file.
That last point matters on deploy: running composer install on the server from a committed lock file gives you the same dependency tree every time, without transferring thousands of files over the wire on each release.
Why this is not a backup
Git holds your code and knows nothing about your database or your media library. A repository restores the application; it cannot restore what your customers did. Full cover means version control for the codebase, daily database backups, and a copy of uploads somewhere off the server.
Each of those three covers roughly a third of the problem. Together they mean a bad release, a bad query and a failed disk are three separate recoveries, each with a procedure you have actually run.
Deployment terms, with the failure modes
Where a tool is commonly mistaken for something it is not, the entry says so plainly and names what covers the gap instead.
Git and Composer come with the developer-focused plans alongside SSH, and staging gives you somewhere to rehearse a deploy before it reaches live.
- Rollback timed, not assumed
- The .git exposure check included
- What belongs in the repo, listed
- Backup gaps named explicitly
Why HostingFast
Standard on every plan
Recovery with a time attached
What a checkout costs against what a full restore costs, including the state a restore would undo.
An exposure check you can run
The curl request that tells you whether your repository history is being served to the public.
A clear line on secrets
Why committing a credential is permanent even after removal, and what to do with configuration instead.
Deterministic dependencies
Building from a lock file on the server rather than shipping a vendor directory over the wire.
Honest about coverage
The parts of a site version control cannot protect, and the two other mechanisms that do.
Rehearsal built in
Using staging as the place a deployment procedure gets tested before it is trusted on live.
Quick Start
From order to online
- 1
Check /.git is not reachable
curl your own site for /.git/HEAD. Anything other than a 403 or 404 needs fixing before you read the next line.
- 2
Tag the release you deploy
A named tag is what makes rollback one command instead of a hunt through commit hashes at an unhelpful hour.
- 3
Rehearse the rollback on staging
Deploy, break it deliberately, roll back, and time the whole loop. That number is your actual recovery time for code faults.
Built In
Loaded onto every plan
- SSH, Git and Composer on the developer-focused plans
- Staging you can clone, break and throw away before anything reaches live
- Daily backups with a self-service restore you run yourself from the panel
- PHP version selectable per site, switched from the control panel in seconds
- NVMe on every tier — the entry plan runs the same drives as the top one
- LiteSpeed compiled into the server, not a caching plugin bolted on afterwards
- In-place upgrades between plans — no migration when you outgrow one
- A human on support at any hour, including for the awkward questions
- Zero setup fees, on any plan, ever
- Money-back cover: 30 days on hosting plans, 7 on reseller
Frequently Asked
What people ask us most often
Is Git worth it for a site nobody else works on?
Yes, because the benefit is reversibility rather than collaboration. Every change becomes traceable and undoable, and a bad release stops being an emergency. The handful of commands involved — pull, checkout, tag — take an afternoon to learn and repay it the first time something breaks.
How do I deploy from Git without exposing the repository?
Keep a bare repository outside the document root and use a post-receive hook to check the working tree out into place. Where that is not possible, deny access to .git in .htaccess. Either way, verify with curl afterwards rather than assuming the rule matched.
Is staging an add-on, or part of the plan?
Part of it, on the plans that carry it. Clone the live site, do the work on the clone, then push it live once it behaves. That is the whole difference between hoping an update survives contact with production and knowing it does before a visitor ever meets it.
Do I get shell access on shared hosting?
On the developer-focused plans, yes — SSH, Git and Composer included. Every account runs isolated, so a shell session reaches your files, your databases and your processes and nothing beyond them. That is what makes WP-CLI and push-to-deploy workflows practical without renting a VPS.
Keep reading
WordPress
The PHP application under four in ten websites, and what decides its speed.
Staging Environment
A private clone of live, and the only honest place to measure a change.
Best Hosting With Git Deployment
Hosts where push-to-deploy actually works, judged on SSH, hooks and rollback speed.
Joomla Hosting
Joomla in one click, with the existing site migrated across for you.
CMS Hosting
Tuned hosting for WordPress, Joomla, Drupal and the rest, with caching configured properly.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Deploy with one pull, undo with one checkout.
SSH, Git and Composer on the developer plans, staging to rehearse on, and daily backups covering everything Git does not.
View Joomla Hosting plans