Version Control Systems
Git is one kind of version control system (VCS). To understand Git well, it helps to understand the general category of tools it belongs to, what problems they all solve, and what makes Git different from the ones that came before.
What is version control?
Version control is the practice of tracking changes to a set of files over time so you can recall any earlier version, see who changed what, and combine changes from multiple people without losing work.
That definition has three pieces. A real VCS does all three:
Track changes over time — every commit (or revision) is recorded with a timestamp, an author, a message, and the full content (or diff) of the change.
Recall earlier versions — you can go back to any past state, compare two states, and undo changes.
Combine work from multiple people — when two contributors change the same project, the VCS helps merge their changes intelligently rather than silently losing one of them.
The three generations of VCS
Version control software has evolved through three big stages. Each stage solved problems the previous one had.
Generation 1: Local VCS (1970s–1980s)
The very first version control tools stored all history locally — in a database on the developer’s machine. Examples: RCS (Revision Control System), SCCS.
How it worked:
Each file had its own “versions” database in a sibling folder.
To edit a file you would check it out — RCS would unlock it and let you change it.
When you finished you would check it in — RCS would store the diff and unlock the file.
Why it failed:
No collaboration — the database lived on one computer.
No project-level history — only per-file history.
No way to share with a team without copying the whole folder around.
Generation 2: Centralized VCS (CVCS, 1990s–2000s)
The next generation kept all history on a central server, with each developer holding only the current copy of the files (sometimes called a working copy). Examples: CVS, Subversion (SVN), Perforce, TFS.
How it works:
There is one server that has the full history of the project.
You check out the latest version onto your machine to work on.
You commit changes back to the server. Your commit becomes immediately visible to everyone.
You update to pull other people’s commits down.
Strengths:
Centralised history. Everyone agrees on what the “real” state of the project is — it lives on the server.
Simple permission model. The server decides who can read and write.
Easy for non-developers to understand. Conceptually similar to network file shares.
Weaknesses:
Network-dependent. No server = no committing, no branching, no diffing.
Single point of failure. If the server dies and there is no backup, the entire history is gone.
Slow branches. Branches in SVN are copies on the server — heavyweight enough that people avoided them.
Slow merges. Merging branches was painful and error-prone, so teams shied away from feature branches.
Generation 3: Distributed VCS (DVCS, 2005–today)
The current generation gives every developer the entire history as a local copy. Examples: Git, Mercurial (hg), Bazaar, Darcs, Fossil.
How it works:
You clone a repository. You get the full history — every commit, every branch — onto your machine.
You commit locally. No network needed. Your commits live in your local copy until you push them.
You pull and push between repositories (which may be peers, or by convention one might act as a shared “server”).
There is no built-in concept of a central server. Teams pick one by convention (e.g., the GitHub-hosted “origin” remote).
Strengths:
Fast. Most operations are local — no network round-trip.
Resilient. Every clone is a complete backup. If the central host disappears, any clone can become the new origin.
Cheap branching. Branches are just movable pointers. Encouraged for every feature, fix, and experiment.
Offline-friendly. Commit, branch, diff, log — all available without internet.
Easier merging. The DVCS data model was designed for frequent merging from the start.
Trade-offs:
Steeper learning curve. Concepts like rebasing, remotes, and the staging area take time to internalise.
Bigger clones. You download the full history, which can be large for old projects.
No single authority. Teams have to choose their conventions (who reviews, where the canonical copy lives, how merges happen).
Quick comparison
Aspect | Local VCS | Centralized VCS | Distributed VCS |
|---|---|---|---|
Example | RCS, SCCS | CVS, SVN | Git, Mercurial |
Where is history stored? | Local DB next to file | Central server only | Every clone has full history |
Network required? | No | Yes (for most actions) | No (for daily work) |
Cost of branching | N/A | High | Trivial |
Risk of total loss | High | Medium (one server) | Low (many copies) |
Merging philosophy | Rare | Avoided | Frequent and cheap |
Why Git won
Among distributed VCSes, Git became dominant for several reasons:
Linux endorsement. When the Linux kernel community adopted Git in 2005, it instantly proved itself on one of the world’s biggest codebases. That credibility was hard to match.
GitHub. The 2008 launch of GitHub made Git accessible — a clean website, free public repos, and a workflow (forks + pull requests) that made open-source collaboration delightful.
Speed. Even on enormous repos, Git was — and is — extremely fast for daily operations.
Branching. Git made branches so cheap that teams could afford to use them for every change. That enabled the modern feature-branch / pull-request workflow.
Network effects. Once Git had a critical mass of developers and tooling, every new tool integrated with Git first. Mercurial — arguably as good technically — slowly faded as the ecosystem coalesced around Git.