The problem it solves
Most people have met the folder full of files named report_final.docx, report_final_v2.docx and report_final_v2_REAL.docx. Nobody is sure which one is current, what changed between them, or who made the last edit. Add a second person editing at the same time and the confusion grows quickly.
Version control is a system that records changes to a set of files over time. Instead of copying files and renaming them, you tell the tool when a meaningful change is complete, and it stores a snapshot together with a note about what changed and who changed it. You can then look back, compare two points in time, or return to an earlier state.
It is most closely associated with software, but the idea applies to anything that is edited repeatedly: firmware, scripts, configuration files, test procedures, documents written in plain text, and, with some limits, design files.
Why technical teams use it
The benefits tend to fall into a few groups.
- A reliable history. Every recorded change has an author, a date and a message. When something breaks, you can ask what changed since it last worked.
- Safe experiments. You can try an idea on a separate line of work without disturbing the version everyone else depends on.
- Collaboration. Several people can work on the same project and combine their changes in a controlled way, rather than emailing files back and forth.
- Recovery. A deleted file or a bad edit is usually recoverable, as long as the work was recorded.
- Accountability and traceability. Teams working under quality or safety processes often need to show what was released and what it contained. A history makes that easier, although the specific requirements depend on your industry and the standards that apply to you.
Version control is not a backup system, though it often serves as part of one. If the only copy of a repository lives on one laptop, a failed disk still loses everything.
Core ideas
Repository
A repository is the project’s folder plus the hidden record of its history. Think of it as the files as they are now, together with every recorded earlier state.
Commit
A commit is one recorded snapshot of the project, with a message. Commits are the unit of history. Good commits are small enough to describe in a sentence and complete enough that the project still works afterwards. The habits that make commit messages useful are covered in the commit messages article of this cluster, so here it is enough to say that a message should explain why the change was made, not just repeat the file names.
History
The history is the chain of commits. Each commit points to the one before it, so you can walk backwards through the project’s life. Most tools can show the history as a list, show exactly which lines changed in each step, and report who last edited a given line.
Working copy and staging
Your working copy is the set of files you are editing right now. Some tools, Git among them, add a staging area: a place where you choose which of your edits will go into the next commit. That lets you split unrelated changes into separate commits even if you made them in one sitting.
Branches and merges
A branch is an independent line of development. You create one to work on a feature or a fix, and the main line stays untouched. When the work is ready, you merge it back. Teams settle on conventions for how many branches to use and how long they live; that is its own topic, and the common branching strategies involve real tradeoffs.
Conflicts
If two people change the same part of the same file in different ways, the tool cannot decide which version is right. It marks the disagreement and asks a person to resolve it. Conflicts are normal and usually manageable, particularly when changes are small and frequent.
Centralised and distributed systems
Older tools used a central server that held the only full history. You checked files out, edited them and checked them back in. Many such systems are still in use, particularly where files are large or access needs tight control.
Distributed systems, of which Git is the best-known example, give every user a complete copy of the history. You can commit, browse history and create branches without a network connection, and you share work by sending commits to and from other copies. In practice, teams still nominate one shared repository, usually on a hosting service or an internal server, as the agreed source of truth.
What a typical day looks like
The details differ between tools, but the rhythm is similar:
- Get the latest shared changes.
- Create a branch for your task.
- Edit files, and record commits as you finish logical pieces.
- Share your branch and ask a colleague to look at it.
- Merge it once it is approved.
The review step is where pull requests normally come in. Reviewers read the proposed changes before they join the main line, which is a natural place for code review to happen. Some teams also run automated checks at that point, which is the territory of continuous integration.
What it handles well and badly
Version control works best with text: source code, configuration, scripts, markdown, CSV data and similar. Text files can be compared line by line, and two people’s edits can often be combined automatically.
Binary files such as CAD models, spreadsheets saved in proprietary formats, images and compiled outputs are harder. The tool can store them and keep their history, but it usually cannot show what changed inside them or merge two people’s edits. Teams often use locking, naming rules or specialised tooling for these, and the approaches differ by product.
Habits that help
- Commit often, in small steps that each make sense alone.
- Write messages that a colleague could understand a year from now.
- Keep generated files and secrets such as passwords out of the repository.
- Agree on a simple team convention for branches and stop there; a short, followed convention beats an elaborate, ignored one.
- Learn how to undo things before you need to. Most mistakes can be reversed if you stop and look first.
- Pair the history with readme files and short notes on important choices, since the history shows what changed but not always the reasoning.
Getting started
For a first project, pick a small folder of text files, put it under version control, and make a handful of commits as you work. Practice looking at the history and comparing two versions. Once that feels natural, add a second branch and merge it. The commands differ between tools, but the concepts above carry over, so time spent understanding them is rarely wasted.
Practices for regulated or safety-related work vary by country and industry, so follow your organisation’s procedures and the standards that apply to you.