A commit names its own content: 40 hexadecimal characters computed over a tree object, one or more parent pointers, an author line, a committer line, a timestamp and a message. Please provide the sentence for rewriting. A version control system built on that object can be audited, merged and rolled back with arithmetic. A version control system that treats history as a folder of saved copies cannot, at any price.
How a commit works
Read one commit out of any Git repository and you have read the whole design.
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
parent 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b
author Anthony Harvey <ah@example.com> 1735689600 +0000
committer Anthony Harvey <ah@example.com> 1735689600 +0000
Set cache headers
Browser-name was doing foo, so we need to do X.
The object name is a hash over every byte above, message included. Change one character and the name changes. That property makes a repository tamper-evident, a merge reproducible, and a rebase produce new commits.
Storage direction is a separate decision with its own cost. Imperial College London's computing guide notes that SCCS stored the full text of the original file plus a forward patch for each later revision, so the common question, give the latest version, got slower with every commit. RCS reversed the direction and stored the latest version whole with back patches for the earlier ones. Ask any system you evaluate which end of the history it stores whole. The answer predicts performance over a repository with a long life.
A branch is a pointer.
A branch reference in Git is a single file of 41 bytes: a 40-character hash and a newline. Creating one costs one file write. Checking one out examines the tree object for the target commit and materialises the working directory from it. No data is duplicated.
Everything downstream follows from that. A diff compares two tree objects. A three-way merge takes two commits and their nearest common ancestor. A rebase replays patches onto a new base, produces new hashes, and abandons the old objects, which is why a rebased branch has to be force-pushed and why no other person should have based work on it.
The Oxford Research Software Engineering course explains the guarantee plainly: No code committed to version control is ever lost unless you work really, really hard at it. The guarantee remains because old objects stay in the database after the branch pointer has moved past them.
Distributed systems make that whole database local. The Sound Software guide notes that in a distributed system the repository lives in hidden files inside the working copy, so a researcher can initialise one in a project folder without asking anyone's permission and push the entire history to a shared server later with one command. The GOV.UK service manual recommends a distributed system on the same grounds: Every developer has a full copy of the code and its history, and work continues when the network does not.
How to commit and review changes
A trustworthy graph is the precondition. The rules you write over it are what a team operates.
The GOV.UK service manual sets the baseline: commit changes with clear messages, group changes according to their purpose, describe what changed and why in the message, link to the supporting story or bug report, and review every change by someone who did not write it. It also requires that the review process does not stop the team deploying regularly or shipping a quick bug fix. Review is a gate.
HMRC's engineering standards are strict requirements. Six of them: you must always be able to build an artefact from source; you must have an effective way to enable multiple contributors; you must enforce commit signing; you must prevent direct changes to the main branch; you must define and adhere to a branching strategy; you must have a plan for rolling back or fixing forward.
Signing is the requirement that changes the character of the history.
This signature can be verified by the version control server, which can reject any changes with invalid or missing signatures.
HMRC requires it at minimum on every branch used to build and deploy artefacts to a deployed environment. That is the correct threshold. An author field is a claim. A verified signature is evidence, and it is the only part of a commit that a server can check without trusting the person who wrote it.
Four numbers to read from the repository
You cannot manage a history you do not measure. These four take a script and a minute.
- Signature coverage on deployable branches: verified signatures as a percentage of commits. Target 100. At 99, an unverified writer has touched code that is delivered.
- Merge to green on main: minutes from the merge commit to a passing build of main. Keep it under ten. Past that, merges queue and developers batch their work into larger, riskier changes.
- Human-resolved merges: merges requiring manual conflict resolution as a percentage of all merges. Under 10 is healthy. Above 20, branch lifetime is the problem and no merge tool will fix it.
- Branches older than 30 days: a count. Each one is a merge you have deferred and will pay more for later, because the divergence grows with every commit on main.
Which version control types apply to most teams?
GitLab's tutorial sorts version control systems into four types: distributed, centralized, lock-based and optimistic. Only the first two describe most installations. Lock-based systems prevent two people editing one file at once. Optimistic systems give each person a private workspace and merge on submit. Git, Mercurial and Subversion sit in the first two categories, and that classification is the only comparison most teams need.
Git. Distributed. The unit of history is the commit graph, addressed by hash over content. GitLab describes it as an open source distributed system used for projects of any size. The Government Digital Service uses it, and the GOV.UK service manual names it as the distributed system of choice for government teams.
Mercurial. Distributed. The same graph model with different commands and a smaller surrounding ecosystem. The Sound Software hosting service runs Mercurial and publishes the EasyMercurial interface, which presents the same window on Windows, macOS and Linux, which matters when a research group spans all three. Sound Software also notes that BitBucket allowed private repositories with up to five users for free, a number that settled the hosting question for a great many small teams.
Subversion. Centralised. * A single server stores the repository, so every access to history requires a network round trip and commits fail without connectivity. Its Windows client support through TortoiseSVN and SmartSVN is the most complete of the three, according to the Sound Software guide, which also notes that as of 2011 Git, Mercurial and Subversion were the three free systems common enough and capable enough to be good first choices.
The selection procedure is short, and Sound Software gives it in the correct order: what the people you work with already use, where the code will be kept, and the quality of the tools, interfaces and documentation. Compatibility first, hosting second, ergonomics third. A team that picks the technically superior system and then works alone has gained no advantage.
What a working repository looks like at ninety days
At ninety days a repository that is working looks like this. Main builds, and it builds signed. The commit log is a list of reasons. No branch is older than the current sprint. The rollback path has been exercised once against a real environment, so the fix-forward plan is a decision and not a hope.
Version control systems differ in commands, hosting and speed. They do not differ in what good looks like. Immutable commits, a graph you can rebuild, rules the server enforces, and four numbers viewed once a month.
