Cloud Parts

Version control

Record every change to the code as a commit, so anyone can see who changed what, when and why, and get any earlier version back.

1 technology on this page ↓

How it works

A version control system keeps a repository: the full history of a project as a chain of commits. Each commit is a snapshot of the files plus who made it, when, a message saying why, and a pointer to the commit before it. A branch is a named line of commits, so people can work on separate changes at once; a merge joins two branches back together, and the tool combines the edits automatically unless two people changed the same lines (a conflict a person must resolve). Older, centralized systems such as CVS, Subversion and Perforce keep the history on one server and clients check files out from it. Distributed systems such as Git and Mercurial give every clone the whole history, so commits, branches and logs work offline, and every clone is a backup. Teams still agree on one shared copy, usually on a host like GitHub, GitLab or Bitbucket, where changes arrive as pull requests (GitLab calls them merge requests) that others review and that automated checks test before they are merged. Some organizations keep all their code in one repository (a monorepo), which makes changes that span many projects atomic but needs special tooling at scale; others give each service its own repository (polyrepo), which is simpler per project, but a change that spans several repositories needs several coordinated pull requests.

Think of it as

A lab notebook where every entry is dated and signed and pages are never torn out, and anyone can photocopy the whole book to work on at home and send their new pages back.

Reach for it when

  • Always, for source code, infrastructure definitions, configuration and documentation
  • Several people change the same codebase and need to review and merge each other’s work
  • You need to know which change broke something, and roll it back

Think twice when

  • Storing large binaries, datasets or build outputs directly in Git; use Git LFS, an artifact registry or object storage
  • Committing secrets: anything pushed stays in the history even after a later commit deletes it

A real example

A five-person team keeps a web app in one Git repository on GitHub. A developer creates the branch fix-login-timeout, makes two commits on a train with no network, and pushes when back online. She opens a pull request; CI runs 400 tests in four minutes and a teammate approves it. A week later a bug report points at login, and git log and git blame show exactly which commit touched that line and why.

More on version control

Narrower ideas that build on this one.

Technologies

Specific products, and what each does differently.

What each provider calls it

AWS
AWS CodeCommit (Git); closed to new customers from July 2024, open again since November 2025
Google Cloud
Secure Source Manager; Cloud Source Repositories, closed to new customers since June 2024
Azure
Azure Repos (Git, or TFVC for centralized version control)
Open source & others
Git, Mercurial, Subversion; self-hosted forges Gitea (MIT), Forgejo (GPLv3+) and GitLab CE (MIT); hosted GitHub, GitLab.com, Bitbucket; code review with Gerrit

Centralized or distributed#

Both models track commits and branches; they differ in where the history lives and what that makes cheap.

Centralized (Subversion, Perforce, TFVC)Distributed (Git, Mercurial)
Where history livesOn one server; clients hold a working copyIn every clone; one copy is the agreed shared one
Offline workCommits, logs and diffs against history need the serverCommit, branch, log and diff locally
BranchesA copy of a directory, made on the serverA pointer to a commit, created nearly instantly
Access controlPer path: Subversion can grant read or write on a single directoryPer repository: anyone who can read gets the whole history
Binary filesSubversion’s locking stops two people editing an unmergeable image at onceNeeds an add-on such as Git LFS for large files
Failure modeThe server is a single point of failureEvery clone is a full backup

In code · bash

git clone https://github.com/acme/shop.git && cd shop
git switch -c fix-login-timeout        # a new branch from main

# edit files, then record the change
git add src/session.ts
git commit -m "Extend login session timeout to 30 minutes"

git push -u origin fix-login-timeout   # share it, then open a pull request

git log --oneline -3                   # history, newest first
git blame src/session.ts               # which commit last changed each line

Often confused with

Branching strategiesCommit conventionsCI/CD pipelinesBuild tools
Where it came from1972–2024

Version control started at Bell Labs. In 1972 Marc Rochkind began the Source Code Control System (SCCS), which stored each file’s changes as deltas so any earlier version could be rebuilt. In the early 1980s Walter Tichy at Purdue wrote RCS, which also stored revisions as deltas and, like SCCS, expected people to lock a file before editing it. In 1986 Dick Grune posted the shell scripts that became CVS, which let several people edit their own copies of a set of directories at once and merged their changes afterwards; two years later Brian Berliner rewrote it in C, and it spread widely.

By 2000 CVS’s limits were obvious to CollabNet, which hired developers to write a replacement that kept the basic ideas of CVS “but without the bugs and misfeatures”. Subversion hosted its own code from August 2001. It stayed centralized: one server held the history. Meanwhile the Linux kernel, which had passed patches around by email for a decade, adopted the proprietary distributed tool BitKeeper in 2002. In April 2005 the arrangement broke down and its free licence was withdrawn, and Linus Torvalds wrote that he would have to find an alternative.

He made the first commit of Git on April 7, 2005, and the kernel moved to it nine days later; Matt Mackall announced Mercurial the same month with similar goals. Git handed every developer the full history and made branches nearly free. Hosts such as GitHub, which opened in April 2008, built review around the pull request: a page for discussing a branch before it is merged. By 2022, 94% of respondents to Stack Overflow’s developer survey used Git.

Why it’s built this way

Copy, modify, merge instead of lock, modify, unlock
SCCS and RCS made people lock a file before changing it, which serialized work. CVS let everyone edit their own copy and merged the results, betting that real conflicts are rare. Almost every system since has made the same bet, and kept locking only for binary files.
Every clone holds the full history
With BitKeeper, Torvalds wrote, the people around him had a much easier time merging with his tree and sending him theirs. Git and Mercurial kept that model: everyone has a full repository, works offline, and no single server’s loss means losing history.
Make branches cheap
In Subversion a branch is a copy of a directory made on the server. In Git a branch is a small file holding the hash of a commit, so creating or switching one is nearly instant, and a short-lived branch for every change became normal.
Review before merge
Google’s internal Mondrian tool, and later Rietveld, Gerrit and GitHub’s pull requests, made a second pair of eyes a step in the workflow rather than an afterthought. Hosts can now require approvals and passing checks before a branch may be merged.

Timeline

  1. 1972

    Marc Rochkind starts SCCS at Bell Labs

  2. 1986

    Dick Grune posts the CVS shell scripts

  3. 2001

    Subversion becomes self-hosting on August 31

  4. 2002

    The Linux kernel moves to BitKeeper

  5. 2005

    BitKeeper split in April; Git’s first commit on April 7; Mercurial announced

  6. 2008

    GitHub opens to the public on April 10

  7. 2024

    Google and AWS stop taking new customers for their Git hosting; AWS reverses course in November 2025

Sources21

Improve this page on GitHub