A bank statement lists every transaction in order and the balance that follows each one. You can rebuild a month, dispute a charge, and prove what left the account. That description fits a version control system almost exactly: it records every change to the source, keeps the order, and returns you to any earlier point. The comparison holds until the first branch.
A statement is a line. A repository is a graph. Two developers on separate features produce two lines that must be rejoined, and the cost of the tool sits almost entirely in that rejoining rather than the recording. Atlassian's introduction to version control describes the recording function in the same terms, and is explicit that branching and merging are where teams choose their workflow. That is what the analogy leaves out. Nothing on a bank statement has to compile.
A Repository Is a Graph With a Build Contract
One property has to hold before any tool choice makes sense: the main branch must always produce a deployable artefact. The UK's engineering standards for version control make it a MUST, not a preference: "The 'main' branch of your source code should always be able to be built into an artefact that can be deployed." Work in progress does not merge until it is complete and tested. Feature flags cover the gap between merging a change and enabling it.
Everything else follows. If main builds, every merged change is a release candidate, and a pipeline can act on every push without a human judging whether the tree is safe. That is the assumption continuous integration tools are built on. Break the contract and the pipeline becomes a queue of false alarms. The same contract is what lets build automation tools produce the same artefact from the same commit twice.
The mechanics are shared across every system. GeeksforGeeks sets out the vocabulary: a repository holds files plus their history and metadata; a revision is one saved version, identified by a hash; a branch is a separate copy of the codebase; a commit is a snapshot; a merge combines branches and may require conflict resolution. Distributed systems add a second step, because a commit writes to the local repository and a push publishes it.
That second step is why the distributed model displaced the centralised one. A developer commits on a train, rebases eight times, and pushes once. The server sees a single event. A centralised system commits straight to the server, so every intermediate state is a network round trip and a new failure mode.
The Controls That Make the Cost Pay
A graph is not free. It is a second system to operate, and it earns its place only when the controls around it are enforced. HMRC's list is short, mandatory, and testable.
| Control | Failure it prevents | Enforcement point |
|---|---|---|
| Commit signing | A change committed by an unauthorised key holder | Server rejects unsigned or invalid signatures |
| No direct pushes to main | One person shipping an untested change | Branch protection rules |
| A documented branching strategy | Two teams merging under different assumptions | Written team agreement |
| A rollback or fix-forward plan | An incident nobody has rehearsed | Release procedure |
Commit signing is the control teams skip. It applies public-key cryptography to the commit, the server verifies the signature, and a missing or invalid signature is rejected. HMRC requires it at minimum on every branch used to build and deploy artefacts. The configuration is four lines.
[user]
name = Anthony Harvey
email = [email protected]
signingkey = 4A2B1C9D
[commit]
gpgsign = true
git log --show-signature -1 prints the verification for the commit at HEAD. If that returns nothing, signing is not in force, whatever the policy document claims. A protected main branch is only as strong as the code review platforms that gate the merge.
Branching strategy attracts the most argument. GitLab separates three cases: trunk-based development with short-lived branches, environment-aligned branches for teams deploying through staging and production, and long-lived release branches where several versions stay supported. The choice follows release cadence, compliance requirements, and the number of supported versions. It does not follow preference.
Price the System Before You Commit to It
Hosting is the visible cost. It is not the largest one. SoftwareSuggest's catalogue of version control systems lists a free tier for most of the field and paid entry points between $7 and $23 per user per month.
| Tool | Free tier | Paid entry point |
|---|---|---|
| Git | Yes, open source | $0 |
| GitHub | Yes | $7 per user per month |
| Plastic SCM | Yes | $7 per user per month, $23 on Enterprise |
| Beanstalk | No | $15 to $100 per month by tier |
Read those figures against a merge conflict. One conflict costs one engineer, one context switch, and one review. Twenty conflicts a month at thirty minutes each is ten engineer-hours. At £50 per loaded hour that is £500, before anyone opens the licence line. The licence is not the decision.
The real cost is discipline. Commit signing needs key distribution. Branch protection needs an owner. Rollback needs a rehearsal, because a rollback that ignores database state is not a rollback. HMRC splits the two options cleanly: rolling back affects users who already acted on the new version, and fixing forward needs a hotfix branch based on a commit that is no longer on main. Both need a plan, and the plan needs to run before the incident.
Where the Threshold Sits
Version control pays when the cost of losing a change exceeds the cost of operating the system. That threshold is lower than most teams assume and higher than vendors imply.
A single developer on one machine can run a local repository, which GeeksforGeeks describes as the local model: no server, no network, single user. It recovers a deleted file. It does not recover a laptop.
Two to five contributors on one release stream cross the threshold in the week two people edit the same file. A hosted repository on a free tier covers it. The controls stay optional at that size and become mandatory the moment the artefact reaches anyone outside the team.
Regulated work moves the threshold down, not up. HMRC's requirements apply to any repository whose output reaches a deployed environment, so commit signing, protected main, and a documented strategy are the price of entry rather than an enterprise upgrade.
Migration is a separate calculation. GitLab sets out a seven-step process for moving between systems, and the validation step decides the outcome: branch and tag structures must match, commit history must be intact, permissions must hold, and automation must still trigger after the import. A migration that preserves the files and loses the graph has discarded the thing you were paying for.
When It Stops Being Worth It
The system stops paying for itself when the controls become theatre. Four signals:
- A branch older than 30 days with no merge candidate.
- A merge conflict resolved by discarding one side wholesale.
- A commit pushed directly to main because review was slow.
- A release with no tag, so the deployed artefact cannot be traced to a commit.
Each one means the graph exists and the contract does not. The tool is then recording history nobody trusts.
Choosing which system is the wrong first question. Atlassian's Git tutorial states the position directly:
While it is possible to develop software without using any version control, doing so subjects the project to a huge risk that no professional team would be advised to accept. So the question is not whether to use version control but which version control system to use.
The engineering answer is narrower than that. Adopt one when main can always be built, when every commit traces to an author and a purpose, and when the rollback plan has run at least once outside a live incident. Below that bar the repository is a ledger with a merge button, and the merge button is the expensive part.
Sources
- Best Version Control System: Compare Features & Pricing: catalogue of version control systems with free tiers and per-user pricing.
- Version control - HM Revenue & Customs: mandatory controls for repositories that feed deployed environments.
- What is version control | Atlassian Git Tutorial: the core functions of version control systems and the case for adopting one.
- Version Control Systems - GeeksforGeeks: shared vocabulary and the local, centralised, and distributed models.
- What is version control? | GitLab: branching strategies for parallel release tracks and migration validation.
