If you have ever hired a web developer, you have probably seen words like Git, repository, branch, commit or pull request in an email or an invoice. Most explanations online are written for developers, by developers. This guide is written for the person paying the invoice.
By the end of this article you will understand what version control actually does, why it is the single biggest protection your website has against broken updates, and the exact questions to ask your developer before, during and at the end of a project (especially the uncomfortable one: who owns the code repository?).
What is version control in web development? The short answer
Version control in web development is a system that records every change made to your website’s code, who made it, when, and why, so that any version can be recovered at any time. The most widely used version control system today is Git, usually hosted on a platform such as GitHub, GitLab or Bitbucket.
Think of it as an unlimited, permanent undo history for your website. Not just for the last edit, but for every edit ever made, by every person who ever touched the project, going back to day one.
From a business point of view, version control gives you four things:
- Recovery: a broken update can be reversed in minutes instead of rebuilt from scratch.
- Accountability: you can see who changed what and when.
- Collaboration: several developers can work on the same site without overwriting each other.
- Continuity: if your developer disappears, the full history of your website does not disappear with them.
The Google Docs analogy (the easiest way to understand it)
You already use a simplified form of version control every day. Open a Google Doc and click “Version history”. You will see a list of saved states with names and timestamps, and you can restore any of them.
Version control for a website works the same way, with three important differences:
- It tracks hundreds or thousands of files at once as one single snapshot, not one document.
- Each saved point has a written explanation attached (“fixed checkout button on mobile”).
- Developers can create parallel copies of the whole project, experiment freely, and only merge the work back in once it is proven to work.
That third point is the one that protects your revenue. Nobody has to experiment on your live website.
The five words your developer keeps using, translated
| Developer word | What it means in plain English | Business equivalent |
|---|---|---|
| Repository (repo) | The project folder containing your code plus its complete history | The master filing cabinet for your website |
| Commit | A saved snapshot of the project with a note explaining the change | A dated, signed entry in a logbook |
| Branch | A parallel copy of the project used to build or test something new | A working draft kept separate from the signed contract |
| Merge | Folding the tested work from a branch back into the main version | Approving a draft and filing it as final |
| Rollback / revert | Returning the site to a previous working state | Pulling last week’s known-good version out of the cabinet |
Repository: where your website really lives
Your live website is a copy. The repository is the source of truth. It holds the code, the configuration, the theme or template files, and every change ever recorded. If your live server is wiped tomorrow, a healthy repository means the site can be redeployed. If the repository does not exist, or you cannot access it, you are relying entirely on backups and luck.
Commit: the paper trail
Every commit answers three questions automatically: what changed, who changed it, and when. A good project history reads like a maintenance log:
- “Add GDPR cookie banner”
- “Fix contact form not sending on iPhone”
- “Update payment plugin to 4.2.1”
That log is genuinely useful to you as an owner. When something breaks on a Tuesday, the first question is always “what changed recently?” and the commit history answers it in seconds. Source: https://van-ons.nl.
Branch: why your site does not have to be the test lab
This is the concept most business owners find the most reassuring. When a developer needs to rebuild your checkout, add a booking system or redesign your homepage, they create a branch. The live site keeps running untouched while the new work is built and tested in parallel. Only when it is approved does it get merged and deployed.
No branches usually means one thing: someone is editing files directly on your live website. That is how sites go down at 3pm on a Friday.
How version control protects your website from broken updates
Here are the real-world scenarios where version control pays for itself.
1. A plugin or dependency update breaks the site
Without version control: panic, manual reinstalls, guesswork, hours of downtime.
With version control: the update was a commit. Revert the commit, redeploy, site is back. Then diagnose calmly. Originally covered on https://git-scm.com.
2. Two developers work on the same site in the same week
Without version control: one developer uploads files by FTP and silently overwrites the other’s work.
With version control: Git detects the overlap and forces the conflict to be resolved deliberately, before anything reaches the live site.
3. A change looked fine but tanked your conversions
Without version control: you try to remember what the page looked like three weeks ago.
With version control: you restore the exact previous version and compare properly.
4. Your developer becomes unavailable
Without version control: a new developer starts by reverse engineering a mystery. Expect to pay for that discovery time.
With version control: the new team clones the repository, reads the history, and is productive in days rather than weeks.
5. Something suspicious appears on your site
Without version control: you cannot tell modified files from original ones.
With version control: any unexpected change to tracked files stands out immediately, which makes cleanup after a security incident far faster.
Important: version control is not the same as a backup
This confusion causes real damage, so let us be precise. Both matter, and they protect different things.
| Version control (Git) | Backups | |
|---|---|---|
| Protects | Code, templates, configuration | Database, uploaded media, orders, customer data |
| Granularity | Every individual change, with an explanation | Whole-site snapshots at set intervals |
| Answers | “What changed and why?” | “Can we get everything back to yesterday?” |
| Typical use | Reversing a bad deployment | Recovering from server loss or data corruption |
You need both. A repository will not bring back last night’s orders. A backup will not tell you which of forty changes broke the checkout. Any developer who says “we don’t need version control, we have backups” is telling you they do not have a recovery process, only a reset button.
What to ask your developer: 10 questions that take five minutes
You do not need to understand Git commands to run a professional check. Ask these, and listen for confident, specific answers.
About version control and process
- Is my website’s code in a Git repository? Where is it hosted? (Expect GitHub, GitLab, Bitbucket or a self-hosted equivalent.)
- Are changes tested somewhere other than my live site before going live? (You are asking about a staging environment and branches.)
- How do changes get deployed to the live site? (Automated deployment from the repository is the professional answer. “I upload by FTP” is a warning sign.)
About backups and rollbacks
- How often are backups taken, and do they include the database as well as the files?
- Where are backups stored, and are they held somewhere separate from the web server?
- When was a restore last tested? An untested backup is a promise, not a safety net.
- If an update breaks the site, how long does a rollback take, and who is authorised to trigger it? Get a number in minutes or hours, and put it in your maintenance agreement.
About ownership and access
- Who owns the repository and the code in it?
- Is my company the owner of the repository account, or is it inside your personal or agency account?
- At the end of the project, how is the repository, with its full history, transferred to me?
Who owns the code repository at the end of a project?
This is where businesses get hurt, and it is almost always avoidable. Ownership of code is a contractual matter, not a technical one. If your agreement is silent, you may find you have paid for a website whose source code and history you cannot legally or practically take with you.
Put these points in writing before work starts
- IP assignment: custom code written specifically for you is assigned to your company on final payment.
- Repository ownership: the repository lives in an organisation account owned by your company, with your developer added as a collaborator. This is the single most effective clause you can add.
- Full history transfer: you receive the repository with its complete commit history, not a zip file of final files. History is the documentation.
- Third-party components: a written list of any licensed themes, plugins, libraries or APIs used, and who holds those licences.
- Credentials handover: hosting, domain registrar, DNS, repository, deployment tools, analytics, and any environment variables or keys.
- Access removal: departing collaborators lose access at handover, and any shared secrets are rotated.
Handover checklist you can copy
| Item | Received? |
|---|---|
| Repository under our company account, with full history | |
| Admin access to hosting, domain and DNS | |
| Written deployment instructions (how code reaches the live site) | |
| Documented rollback procedure and target recovery time | |
| Backup schedule, storage location and a tested restore | |
| List of licences and third-party services | |
| Signed IP assignment for custom code |
Red flags that suggest version control is missing
- Files are edited directly on the live site, or uploaded manually by FTP.
- Nobody can tell you what changed last week.
- Fixing a broken update means “rebuilding” rather than “reverting”.
- There is no staging or test environment at all.
- Folders on the server named
index-old.php,backup-final-v3orsite_copy_new. That is version control by superstition. - Your developer cannot show you where the repository is.
Does this apply to WordPress, Shopify and no-code sites?
Yes, with nuance. On a WordPress site, the custom theme, custom plugins and configuration should be in version control, while the database and media library are protected by backups. On Shopify, theme code can and should be version controlled. On hosted no-code or website builder platforms you may have limited or no access to code, in which case your protection comes from platform versioning plus documented, exported backups. The principle never changes: every change should be recorded, reviewable and reversible.
Frequently asked questions
What is version control in simple terms?
It is a system that saves a dated, labelled snapshot of your project every time something changes, so any earlier version can be restored and you can always see who changed what and why.
Is GitHub a version control system?
Not exactly. Git is the version control system. GitHub is a hosting platform for Git repositories that adds collaboration features such as access control, code review and issue tracking. GitLab and Bitbucket are alternatives. Simple analogy: Git is the engine, GitHub is the garage. The reasoning is set out in this piece.
What are the main version control systems used today?
Git dominates modern web development. Others still in use include Subversion (SVN), Mercurial, Perforce Helix Core (common in games and large binary projects) and Azure DevOps repositories. For a typical business website, if your developer is not using Git, ask why.
Is SVN better than Git?
For web development, Git is the standard choice because it is distributed, fast, and makes branching cheap and safe. SVN uses a centralised model that some organisations still prefer for very large binary assets or strict central control. For your website, Git is almost certainly the right answer.
Do I need version control for a small five page website?
Yes, and it costs almost nothing to set up. Small sites still break, still get updated, and still change hands between developers. The smaller the site, the smaller the effort and the bigger the relative benefit.
Does version control cost extra?
The tooling itself is free or very cheap, and private repositories are included in the free tiers of the major platforms. What you are paying for is a developer’s disciplined process, which reduces downtime, shortens fixes and lowers the cost of every future change.
Can I see the repository myself without being technical?
Absolutely. Ask for read access. You will see a plain list of dated changes with descriptions, and you can browse them in a browser without installing anything.
The takeaway
Version control is not developer housekeeping. It is operational insurance for a business asset. It determines how fast a broken update gets fixed, how easily a new team can take over, and whether you actually own what you paid for.
You do not need to learn Git. You just need to ask three questions and get clear answers: Where is the repository? How fast can we roll back? Who owns it when the project ends?
If your current setup cannot answer those, that is worth fixing before your next update, not after your next outage. Get in touch and we will review how your website’s code, backups and rollback process are handled.