Version control is a system that keeps a complete history of changes to a set of files, normally a website’s or app’s code, recording what changed, when, who did it and a note explaining why. Any earlier state can be compared with the current one or brought back. Git is by far the most widely used version control tool, and services such as GitHub, GitLab and Bitbucket host Git repositories online.
How version control works
The project’s files live in a repository. When a developer finishes a piece of work, say a new contact form, they save a snapshot of the changed files called a commit, with a short message such as “Add postcode field to enquiry form”. Each commit points to the one before it, so the repository becomes a timeline you can walk backwards through.
Work in progress usually happens on a branch, a separate line of changes that does not touch the main version until it is ready. Two developers can work on different branches at once, and Git merges their work, flagging any line both of them changed. On a well-run website project, changes are tested on a staging site first and then deployed to the live server from the repository, often automatically.
Version control tracks files, not everything that makes a website. On WordPress, the theme, custom plugins and configuration fit neatly in Git. Pages, posts, settings and form entries live in the database, and uploaded images sit in a media folder that is usually excluded. Those need a separate website backup.
Why it matters for a UK business
Plenty of website emergencies are not hacks but ordinary edits that went wrong: an update that broke the checkout, a tweak to the header that hid the phone number on mobile, a freelancer’s change that nobody can explain six months later. With version control, the developer can see exactly which change caused the problem and reverse that one change in minutes, without rolling back everything else.
It also protects you when people change. If your site is built by an agency or a freelancer, the repository is the record of their work. A business that owns its repository can hand it to a new developer who can read the full history. A business whose code only exists on a server the old supplier controls often discovers the problem at the worst moment, in the middle of a redesign or a dispute.
For SEO, the value is indirect but real. Template changes can quietly alter titles, canonicals or heading structure across hundreds of pages. A commit history makes it possible to match a drop in visibility to the date a specific change went live.
Common mistakes
- Editing live files. Changes made through the WordPress theme editor or over FTP bypass the repository, so the next deployment overwrites them or the history no longer matches the site.
- The repository belongs to the supplier. If it sits in the developer’s personal account, you do not control your own code.
- Customising a parent theme directly. Changes belong in a child theme under version control, otherwise a theme update wipes them.
- Secrets in the code. Database passwords and API keys committed to a repository stay in its history even after deletion. They belong in configuration files that are kept out of Git.
- Vague commit messages. “Fixes” and “update” tell nobody anything when you are hunting for the change that broke something.
How to act on it
You do not need to learn Git yourself. Ask whoever maintains your site three questions: is the code in a repository, which account owns it, and how do changes reach the live site? Good answers are “yes”, “an account in the business’s name” and “we test on staging and deploy from the repository”. If the answers are vague, put version control into the brief before any further development work.
When I plan a website redesign, the repository and deployment route are agreed at the start, because they decide how safely changes can be made after launch and how easily the site can be handed on.