Version control is a system that records every change made to a file, or a set of files, over time so you can go back to a specific version later. You can roll one file or a whole project back, compare changes as they happened, and see who changed something and when.
It's best known among software developers, but the idea isn't limited to code. You can use it with nearly any type of file on a computer.
Situations where version control earns its keep
The easiest way to see the point is through the moments it saves you. Each of these maps to something a version control system lets you do:
- One file went wrong. You edited a single document or script and want yesterday's version back. You can revert just that file to a previous state and leave everything else alone.
- A whole round of edits went wrong. Several files changed together and the result doesn't work. You can revert the entire project to an earlier state in one go.
- You need to see how something grew. Comparing changes over time shows what was added, removed or reworded between versions.
- Something broke and nobody knows why. You can see who last modified the part that might be causing the problem, and who introduced the issue and when.
How version control works in practice
There are a few ways people keep track of versions, and they range from a folder of copies to a full history on every machine. The Git project's own book walks through them in roughly this order.
Copying files by hand
The most common manual method is copying files into another directory, often one with a time stamp in its name. It's simple, which is why so many people do it, but it's also error prone. It's easy to forget which directory you're in.
Local version control systems
To get around that, programmers long ago built local systems that keep all the changes to files in a simple database. The history lives with the files on one computer, rather than in a scatter of copies.
Centralised version control
Centralised systems such as CVS, Subversion and Perforce keep every versioned file on a single server. Each person's computer is a client that checks files out from that central place, so a team works from one shared store.
Distributed version control
In distributed systems such as Git, Mercurial or Darcs, a client doesn't just check out the latest snapshot. It fully mirrors the repository, including its full history, so every person working on the project holds the whole record.
The words you'll meet in version control tools
A handful of terms come up again and again once you start reading about these systems. Here's what each one means in plain English:
- Repository: the store that holds the versioned files and the history of every change to them.
- Check out: what a client does in a centralised system to get files from the central server.
- Snapshot: the state of the files at one point in time. Distributed clients get more than the latest snapshot; they get the whole history.
- Clone: your own complete copy of a distributed repository. Because it carries everything, it doubles as a backup.
The weak spot: one server can stop everyone
A central server is a single point of failure. If it goes down, then for as long as it's down nobody can collaborate at all or save versioned changes. The whole team waits on one machine.
Distributed systems get around this by design. Every clone is a full backup of all the data, so if one copy is lost, the history still exists everywhere else it was cloned. No one machine holds the only copy of your history.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Who version control suits
Developers are the obvious users, but it suits anyone whose work goes through many versions: writers with drafts, designers with layouts, or a team editing shared documents. If you've ever saved a file as final, then final-2, then final-really, it's for you.
If your documents already live in SharePoint, our guide to SharePoint version history shows a related way of getting earlier copies back.
The same question is worth asking of any business software where your records change over time. If you run jobs through a specialist package, like the ones in our roundup of pest control software, look in the vendor's help pages for a version history before the day you need one.
Frequently asked questions
Is version control only for programmers?
No. It's most common in software, but you can use it with nearly any type of file on a computer.
Where does Git fit in?
Git is a distributed system, in the same family as Mercurial and Darcs.
Can it tell me who broke something?
Yes. It shows who introduced an issue and when.
Do I need a server to use version control?
Not always. Local systems keep changes in a simple database on your own machine, and only centralised systems depend on one shared server.
Does a centralised system keep the full history on my computer?
No. Only distributed systems give every client the full history.
