Git Released — Torvalds Writes Distributed Version Control in Ten Days

On 3 April 2005, Linus Torvalds began designing a new version-control system. On 7 April, the first self-hosting commit landed—the moment Git began tracking its own source. On 20 April, Linux kernel development formally moved to Git.

From design start to production use, just over ten days. Few episodes in software engineering history match that velocity.

Why was it possible at all, and why did Git displace every prior VCS—CVS, Subversion, Perforce, BitKeeper—and become the world standard? The answer lies in what happened during those few weeks in April 2005.

The BitKeeper Crisis

From 2002 to 2005, Linux kernel development ran on BitKeeper, a commercial distributed VCS developed by BitMover. BitMover granted free licences for open-source use.

Torvalds had chosen BitKeeper for a simple reason: every open-source VCS of the time (CVS, Subversion) was centralised and could not handle the scale of Linux kernel development—thousands of contributors in parallel. BitKeeper was the only realistically distributed option.

In April 2005 the arrangement broke. OSDL's Andrew Tridgell (of Samba fame) attempted to reverse-engineer the BitKeeper protocol—despite BitMover prohibiting commercial BitKeeper users from building competing compatible clients. BitMover CEO Larry McVoy revoked the free licence for Linux kernel use. Torvalds was suddenly without a VCS for a multi-million-line, thousand-contributor project.

Specifications Written in Ten Days

Having lived with version-control problems for more than a decade of kernel work, Torvalds could state the requirements immediately. From his early mailing-list posts:

1. The opposite of CVS. He disliked CVS; the new system would be unlike CVS in every detail.
2. Distributed. All repositories are peers. No central server.
3. Fast. Merge, diff, log should feel instantaneous.
4. Integrity guaranteed. History must be tamper-evident (SHA-1 hashes).
5. Built for huge projects. The Linux kernel—then about eight million lines—must work practically.

The pivotal choice was content-addressable storage. Files, trees, and commits are all identified by SHA-1 hashes of their content. "Address" means "what is inside", not "what it is called". Identical content is automatically deduplicated. The integrity of history is mathematical, not procedural.

"The Stupid Content Tracker"

Torvalds called early Git "the stupid content tracker". The design ethic: "Smart VCSes do not trust the user. Git trusts the user and gives them primitives."

The earliest Git did not have a friendly CLI. It was a collection of low-level commands (the "plumbing")—git commit-tree, git update-ref, git read-tree—that manipulated internal data structures directly.

The friendlier upper-level commands (the "porcelain")—git commit, git checkout, git merge—were built up from mid-2005, led by Junio Hamano. In July 2005 Torvalds handed the maintainer role to Hamano. For more than twenty years since, Hamano has remained the principal Git maintainer.

Why Git Won

In 2005, other distributed VCSes existed:

• Mercurial (Hg) — started by Matt Mackall around the same time, with a similar design
• Monotone — 2003; influenced Git's content addressing
• Darcs — 2002; based on patch theory but slow
• Bazaar (Bzr) — 2005, backed by Canonical (Ubuntu)

Two factors gave Git the lead.

The Linux kernel as flagship project. That the largest open-source project in the world ran on Git was a powerful reference. "If it works for Linux, it works for us."

GitHub (2008). GitHub hid Git's harsh edges behind a web UI and added social features (fork, pull request, issues). For individual developers, Git became approachable for the first time. Bitbucket—originally built around Mercurial—eventually retired Mercurial support and moved to Git (2020).

Git as Infrastructure

In 2026, Git's dominance is near-total:

• GitHub — 150 million users, 420 million repositories (as of GitHub's 2024 disclosures)
• GitLab — the standard for self-hosted enterprise
• Bitbucket — the Atlassian developer ecosystem
• Gitea / Forgejo / Codeberg — open-source GitHub alternatives

Git is no longer merely a VCS:

• CI/CD — a Git push triggers deployment
• GitOps — Kubernetes cluster state is described in a Git repository
• Code review — the pull request is the standard workflow
• AI training data — public GitHub repositories are training corpora for LLMs
• Incident forensics — commit history is evidentiary

Software written in ten days by Linus Torvalds has become, twenty years later, the recording substrate of the world's intellectual production in code.

From SHA-1 to SHA-256

Git's SHA-1 hashing was downgraded to "cryptographically broken" after Google published the SHAttered collision attack in 2017. Git has been migrating to SHA-256 since 2018; the rollout has spread through 2024-2025.

Crucially, the design principle of content addressing is unaffected. Swapping SHA-1 for SHA-256 changes the hash function, not the mental model. The longevity of a design Torvalds wrote in ten days is part of the story.

What It Showed

Git 2005 is a case study in what an experienced designer can produce under extreme constraint and necessity in ten days.

The more important consequence, though, is that distributed version control as an abstraction reshaped collaboration itself. Pull request, code review, branch, merge—this vocabulary, in 2026, has spread beyond engineers to translators, data scientists, and writers.

Torvalds has repeatedly said that he had no ambition to change the world with Git—he only wanted to keep developing the Linux kernel. The software he wrote in ten days became the recording medium of nearly every software project on earth.