version control
Version control is a system that records every change made to a site's code, so any change can be reviewed and any change can be undone.
Version control is the practice of recording every change made to a piece of code as its own distinct, permanent entry, rather than just keeping one current copy that gets overwritten each time. Every change has an author, a timestamp, and a description of what changed. Nothing is silently lost, and nothing has to be reconstructed from memory.
The tool I use for this is Git, and the changes live in a GitHub repository. But the concept matters more than the specific tool. Without version control, a site’s code is one fragile, current state. With it, the code has a complete, searchable history that stretches back to the first line ever written.
This is standard practice for any real software project, and it is one of the clearest differences between a site built as code and a site built on a platform where changes just happen invisibly in the background with no record kept.
Why it matters to you
Things go wrong on live sites. A change breaks a layout, a form stops submitting, a page disappears. Without version control, fixing that means guessing what changed and hoping the fix does not break something else. With version control, the fix is precise: find the exact change in the history, and reverse only that change.
It also protects you from a specific, quieter risk: a developer, including me, making a mistake. Version control means a mistake is always recoverable. Nothing is ever a one-way door.
How I set it up
Every project I build lives in Git from the first commit. Each change, however small, gets its own recorded entry with a description of what it does. That history ships alongside the code in the GitHub repository, so it is not something separate you would have to ask for later, it is built into how the site exists from day one.
When I make changes after launch, the same discipline applies. Nothing gets edited directly on the live site with no record. Every change goes through the same recorded process, whether it is a typo fix or a new page.
What it looks like in practice
You will likely never open the history yourself. What you will notice is how fast a problem gets fixed when one comes up: instead of a lengthy investigation, I can look at the exact sequence of changes and identify the one responsible in minutes.
It also means a crawl of the site done for a proposal or an audit reflects a real, traceable state of the code, not a guess about what is currently live. Everything is accounted for, because everything was recorded as it happened.
Questions I get about this
- Isn't this just a fancy backup?
- It is more precise than a backup. A backup gives you one snapshot to restore from. Version control keeps every single change as its own recorded step, so you can see exactly what was different at any point in the site's history, not just roll back to one earlier copy.
- Do I need to do anything to keep version control working?
- No. It runs automatically every time code changes, as part of how the site is built and deployed. There is no separate task to remember.
- Why does this matter if I never touch the code myself?
- Because if something on the site ever looks wrong, version control is how it gets fixed fast. Instead of guessing which recent change caused it, I can look at the exact history and reverse the one change responsible, with nothing else affected.
Want this set up properly for your business?
This is the kind of thing I build every week. Grab a time and we will talk through what fits.