Version control records every change to a body of work — what changed, who changed it, and why — as an unbroken, reversible history. Git is the one that won. It's the substrate that makes software reproducible, reviewable, and auditable, and the safety net that lets you hand real leverage to an AI agent without handing over the keys.
A version control system (VCS) tracks changes to files over time so you can recover any past state, see exactly what changed between two points, and work in parallel without overwriting each other. Before version control, "the latest version" was a folder called final_v3_FINAL_actually.zip and a prayer. After it, the project's entire history is a queryable, attributable ledger.
Git, created by Linus Torvalds in 2005 to manage the Linux kernel, is the system the industry standardised on. It's distributed: every clone is a full copy of the history, so there's no single point of failure and you can work offline. It's now the near-universal default — the thing GitHub, GitLab, and every coding agent are built around.
Git is the version control system — the engine, running on your machine. GitHub (and GitLab, Bitbucket, Codeberg) are hosting platforms built on top of Git that add collaboration: shared remotes, pull requests, issues, CI. You can use Git with no platform at all. This leaf is about the engine; the GitHub & code repositories leaf is about the platforms.
Git has a deep feature surface, but day-to-day it comes down to four primitives. Understand these and the rest is detail.
A snapshot with a message, an author, and a timestamp. Small, attributable, and reversible — the atom of the whole system.
A cheap, isolated copy where you try a change without touching what works. The default branch (usually main) is the one that ships.
Combining a branch back into main. Git reconciles changes automatically and flags conflicts when two edits touch the same lines.
log, diff, and blame answer "what changed, when, by whom, and why" for any line of the project, going back to the first commit.
The everyday loop: branch off main, make commits as you work, push the branch to a shared remote, open a change for review, and merge once it's approved and the tests pass. That loop is identical whether the author is a person or an agent — which is exactly why it's the safe way to let an agent change a system.
Other systems still exist and occasionally fit better. Honest positioning:
| System | Model | Where it fits |
|---|---|---|
| Git | Distributed; every clone is full history | The default for ~everything. Huge ecosystem, every platform and agent supports it. |
| Mercurial (hg) | Distributed, similar to Git | Simpler command surface; a few large shops use it. Niche now — Git's network effects won. |
| Subversion (SVN) | Centralised; one server holds history | Legacy enterprise repos. Centralised model is a liability; migrate when you can. |
| Perforce / others | Centralised, file-locking | Game studios and very large binary assets (art, builds) where Git struggles with size. |
For almost all 2nth work — code, infrastructure, prompts, skills, docs, finance rules — the answer is Git. The interesting choice isn't the VCS; it's the platform you host it on and the workflow you run on top. Both are covered in the GitHub leaf.
The most under-rated thing version control gives you isn't the ability to undo — it's memory. Six months on, "why is this code like this?" has an answer: git blame points at the commit, the commit message explains the intent, and the linked pull request holds the discussion. That chain turns tribal knowledge that walks out the door when someone leaves into a durable, queryable record.
This is the same compounding logic that runs through the whole 2nth tree. Knowledge captured as committed, reviewed change accumulates; knowledge held in someone's head or a chat thread evaporates. Version control is the mechanism that makes the difference.
Anything that's text benefits: infrastructure definitions, agent and prompt configs, SKILL.md files, finance consolidation rules, design decisions, even documents. The 2nth pattern is to put the source of truth in Git so every change is reviewed, attributable, and reversible — then generate the rendered output (a site, a report, a deployment) from it.
The reason you can let a coding agent loose on a real codebase is version control. Its work lands on a branch, not on main. The change shows up as a diff a human can read before anything ships. Tests in CI run against it automatically. It arrives as a pull request that a person (or another agent) approves. And if it's wrong, git revert takes it back cleanly.
Strip version control away and an autonomous agent editing your systems is terrifying — unattributable, unreviewable, unrecoverable. Add it back and the same agent becomes a force multiplier you can actually trust, because every move it makes is bounded by the same gate every human change goes through. That's not a nice-to-have for AI; it's the precondition.
Because the exact state of a system is pinned to a commit, you can reproduce any past result, bisect to find which change introduced a regression, and prove what was deployed when. For AI systems — where "it behaved differently today" is a common complaint — being able to pin behaviour to an exact, committed version is the difference between debuggable and haunted.
Regulated SA environments have to demonstrate change control: who altered a system touching personal or financial data, when, with whose sign-off. Version control provides exactly that, for free, as a side effect of normal work — every change attributable to a person, every deployment traceable to a reviewed commit. A team already working in Git is most of the way to a defensible change-management story; a team emailing zipped folders is not.
Practical note for SA teams: distributed VCS plus a hosted remote is also load-shedding-resilient. Because every clone is a full copy of the history, work continues offline and syncs when connectivity returns — no dependency on a single always-on server.