The Version Control Landscape

Updated

October 30, 2026

The Version Control Landscape

After this page you can say what version control is for, why Git is the usual tool, and what a forge is.

Why you need a history

Without version control, a desk project grows copies:

desk-api/
├── app.py
├── app_backup.py
├── app_final.py
├── app_final_v2.py
└── app_really_final_fixed.py

You lose which file is current, who changed the login line, and any way to undo Tuesday without also undoing Wednesday. Two people editing app.py overwrite each other.

A version control system (VCS) keeps one tree of files, a history of snapshots, and a way to merge parallel work.

Three generations

Generation Idea Examples
Local History on one disk SCCS, RCS
Centralized One server is the repository CVS, Subversion, Perforce
Distributed Every clone is a full repository Git, Mercurial

Local tools recorded deltas next to the files. Fine for one person on one machine.

Centralized tools put the real history on a server. You check out a working copy. Committing needs the network. If the server dies, history you do not have locally is gone.

Distributed tools give every clone the whole history. git commit is a local operation. A remote is another copy you push to when you choose. That is why Git works on a train, and why rewriting commits you already shared is a people problem.

Why Git

Git won the ecosystem. The properties that matter for this book:

  • A commit is a snapshot of the whole tree, not a pile of patches as the primary model.
  • A branch is a cheap name for one commit. Merging and rebasing are graph operations.
  • Object names are hashes of content. Bit flips show up as missing or mismatched objects.
  • Log, diff, commit, branch, and merge all work without a network.
  • Hosting platforms speak Git remotes. Learning Git is not loyalty to one website.

Git vs Subversion, the comparison that still comes up:

Git Subversion
Architecture Distributed Centralized
Offline commit Yes No
Branch A name on a commit A copy in the tree
Typical remote Any number One canonical server

Mercurial is also distributed. Git is what forges, CI systems, and GitOps engines speak.

What a forge is

A repository is a directory Git is tracking (the .git folder plus your files).

A forge is a Git hosting platform: the website and services around repositories. Issues, pull requests, CI, packages, and user accounts live on the forge. GitHub, GitLab, Forgejo, Bitbucket, Gerrit, and SourceHut are forges. This book treats Git first, then the platforms.

Git is the tool. The forge is the product you log into. GitOps (later) is the idea that the same Git history should drive what runs in production.

What Git is not

  • Not a backup by itself. A single laptop clone can die; you still need remotes and backups.
  • Not a file-sync tool. Dropbox overwrites. Git records snapshots and asks you to merge.
  • Not GitHub. You can use Git for years with a forge you run yourself, or with no forge at all.

Next

The next pages are how Git thinks: a graph of commits, three trees on disk, four object types, names for those objects, and what “distributed” means for a server.