Git, how Linus wrote a version control system in two weeks

Field note. If you've ever cloned a modpack repo, recovered a server file from git, or filed a bug against a server plugin: you're using something Linus wrote in two weeks because nothing else worked.

In April 2005, Linus Torvalds wrote the first version of Git. He needed it. The Linux kernel project was suddenly without a version-control system, and the existing tools didn't fit. So he wrote his own.

Within years, Git became the dominant version-control system in software development. By 2026, the vast majority of software is developed using Git. The two weeks Linus spent on it have shaped how millions of programmers work.

This is the story.

What version control is

A version control system (VCS) tracks changes to files over time. It lets developers:

• See who changed what, when.
• Revert to previous versions.
• Work on different features simultaneously (branches).
• Merge changes from multiple developers.

VCS predates Git by decades. Pre-Git tools:

• SCCS (1972): the original.
• RCS (1982): improvement.
• CVS (1990): network-aware. Long-dominant.
• Subversion (2000): replaced CVS for many.
• Perforce, ClearCase, Visual SourceSafe: commercial options.

These were mostly centralized: one server held the canonical version. Developers checked out, made changes, committed back.

Linux's BitKeeper era (2002-2005)

The Linux kernel had a unique problem: thousands of contributors worldwide, hundreds of patches per day, complex merge workflows. Existing open-source VCSes (CVS, Subversion) didn't scale to this.

In 2002, Linus adopted BitKeeper, a commercial distributed VCS by BitMover. BitKeeper was good at the kernel's workflow. It was also commercial.

BitMover gave Linux a free license, with conditions. One condition: developers couldn't reverse-engineer BitKeeper or build competing tools.

In April 2005, a Linux developer (Andrew Tridgell, famous for Samba) started reverse-engineering BitKeeper's protocol. BitMover revoked the free license.

Linux suddenly had no VCS that fit. Linus refused to go back to CVS or Subversion. He decided to write his own.

Two weeks

Linus's goals for the new VCS:

• Distributed. Every developer has a complete repository copy. Operations are fast and offline-capable.
• Fast. Handle large repositories with many files and many revisions.
• Cryptographically robust. Every commit is identified by a SHA-1 hash; you can't quietly modify history.
• Branching is cheap. Encourage frequent branch-and-merge workflows.
• Workflow-flexible. Don't dictate a workflow; provide tools.

He named it Git (British slang for an unpleasant person; he joked he names projects after himself).

The first commit to Git's repository is dated April 7, 2005. Within days, Git was self-hosting (Git's own development used Git). By June, the Linux kernel had migrated to Git.

The whole effort: two to three weeks for a working version. Refinements continued, but the architectural decisions were made early.

What made Git different

Three core ideas:

Snapshots, not differences. Most VCSes track changes between versions. Git stores complete snapshots of the project at each commit. Common content is deduplicated. This makes many operations faster.

Cryptographic identity. Every object in Git (files, commits, trees) has a SHA-1 hash as its identity. References across the history are by hash. You can't modify history without changing all subsequent hashes.

Local-first. Every operation works locally without network. You can commit, branch, merge, look at history, all offline. Network is only needed to share with others.

These choices gave Git its speed and reliability. They also made it different from CVS/Subversion in ways that were initially confusing for users used to those tools.

The learning curve

Git is famously confusing for new users. Common complaints:

• Many commands, each with many options.
• Conflicting terminology (branch, ref, head, etc.).
• Hard to recover from mistakes if you don't know the magic incantation.
• The staging area concept is unintuitive.
• Merge conflicts.

A famous XKCD comic from 2015 summarizes the experience: "git: just memorize these shell commands and type them to sync up. If you get errors, save your work elsewhere, delete the project, and download a fresh copy."

The internal model of Git is consistent and clean. The user-facing commands are a thin shell over the internal model. The mismatch causes confusion.

Despite this, Git won. Adoption proceeded because the benefits (speed, distributed model, branching) outweighed the learning curve.

GitHub (2008)

In April 2008, three developers (Tom Preston-Werner, Chris Wanstrath, P.J. Hyett) launched GitHub. The pitch: a hosted Git service with a friendly web interface, social features, and easy collaboration.

GitHub's choices:

• Free public repositories. Open-source projects could host for free.
• Pull requests (a workflow where contributors propose changes to maintainers).
• Issue tracking.
• Code review tools.
• Social features. Follow developers, star projects, contributor graphs.

Within years, GitHub was the standard place for open-source projects. The "Octocat" mascot became ubiquitous in software development.

Microsoft acquired GitHub in 2018 for $7.5 billion. By then, GitHub was the home of most active open-source. The acquisition was watched nervously but Microsoft has mostly run GitHub well under its ownership.

By 2026, GitHub hosts an estimated 100 million+ repositories and 100 million+ developers. It's the de facto center of open-source.

Competitors

GitHub isn't alone:

• GitLab (2011): self-hostable, with strong CI/CD focus.
• Bitbucket (Atlassian): tied to the Jira ecosystem.
• Codeberg: small, open-source, non-profit.
• Self-hosted Gitea, Forgejo, etc.: lightweight alternatives.

GitLab and Bitbucket have meaningful enterprise use. GitHub remains dominant for open-source.

What Git enabled

Beyond just version control:

Open source collaboration at scale. Pull requests, code review, public repositories. The "fork and contribute" pattern is Git-native (and GitHub-popularized).

Continuous integration. Modern CI systems hook into Git events. A push triggers builds, tests, deploys.

Infrastructure as code. Configurations stored in Git, applied via tools. Terraform, Ansible playbooks, Kubernetes YAML.

Branching and feature workflows. Teams develop in branches, merge to main, all without friction. Git Flow, GitHub Flow, trunk-based development: all leverage Git's branching.

Distributed teams. Developers in different timezones working on the same code. Git's distributed model fits remote work.

Software supply chain. Cryptographically verified history. Reproducible builds. Some security guarantees from Git's design.

What broke

Git's adoption mostly replaced older systems gracefully. Some friction:

• Migration cost. Moving from Subversion or Perforce to Git is significant work for large projects.
• Different mental model. Distributed VCS is different from centralized. Re-training was needed.
• Large files. Git is good with text. Bad with multi-gigabyte binary files. Git LFS (Large File Storage) emerged as a workaround.
• Some legacy systems didn't migrate. Microsoft used a proprietary VCS for Windows for years (Source Depot, then Git as monorepo through specialized tooling).

By 2020, Git was the default for new projects in essentially all software development. Older systems persist in legacy contexts.

Conway's law and Git

Git encourages certain workflows:

Many small commits. Each is a focused change.

Feature branches. Develop in isolation, merge when ready.

Code review via pull requests. Discussions about changes, not just changes themselves.

Open contribution. Anyone can fork, modify, propose changes back.

These workflows shaped how software gets developed. "The way we work" in 2026 is partly "the way Git made convenient."

Linus's design choices

A few specifics worth noting:

Content-addressed storage. Files are stored by hash, not by name. Same content stored once, even if referenced many places.

Immutable objects. Once an object exists, it doesn't change. Modifying creates a new object with a different hash.

Three-way merges. Git can merge changes from multiple branches automatically, falling back to user intervention only on conflicts.

Rebase as alternative to merge. Rewriting history vs. preserving it. Causes much debate.

The staging area (index). A "ready to commit" zone separate from the working directory and from committed history. Unique to Git and confusing to many.

These are technical choices made early in 2005 that have shaped the tool ever since. Some have been refined; the fundamentals are unchanged.

Git's mental model

For users, the key insight: Git stores snapshots of your project linked together.

• A commit is a snapshot plus metadata (author, message, parent commits).
• A branch is a name pointing to a commit.
• The current HEAD is the branch (or commit) you're working on.
• Operations move HEAD around: checkout to switch, commit to add a new snapshot, merge to combine branches.

This model is elegant. The commands feel less so because they accumulated over years. The model is what to internalize.

The SHA-1 problem and SHA-256

Git's identity is based on SHA-1 hashes. SHA-1 was state-of-the-art in 2005. By 2017, it was known to be cryptographically broken (collisions could be found).

Git has been transitioning to SHA-256 (a stronger hash). The transition is slow because Git's data structures use SHA-1 hashes pervasively, and all tools need to be updated.

By 2026, the transition is partially complete. SHA-256-enabled Git exists; most workflows still use SHA-1. The eventual full transition will take more years.

This isn't a critical security issue (the attacks require enormous compute), but it's a real concern for the long term.

The "two weeks" framing

Linus famously said Git was "written in two weeks." This is approximately true but with caveats:

• The initial design and working prototype: about two weeks.
• The mature, refined Git that everyone uses today: years of subsequent development.
• Many improvements came from Junio Hamano, who has been Git's primary maintainer since 2005.
• The community ecosystem (hosting, tooling, integrations) was developed by thousands of contributors.

"Linus wrote Git in two weeks" is a great story. The fuller reality: Linus designed Git in two weeks. The world built it over the following two decades.

Conclusion

Git is the version-control system of 2026. Almost all software development uses it. The interface is famously rough; the model underneath is elegant. The combination has been good enough to dominate for nearly 20 years.

Like Linux, Git emerged from Linus's pragmatic need-solving. Like UNIX before it, Git's design has proven adaptable across many use cases beyond the one it was designed for.

For anyone in software, Git is foundational. Spending time understanding its model (not just its commands) pays off. The model is consistent; the commands are an artifact of accumulated history.

End of Series D

Eight articles on computing history complete:

1. Bell Labs and UNIX.
2. The C language.
3. The PC era.
4. Linux.
5. GNU and Stallman.
6. The rise of open source.
7. Containers, Docker, Kubernetes.
8. Git.

These cover the foundational software history that makes the modern internet possible. The internet runs on these things. Knowing where they came from helps understand why they look the way they do.

Series E (gaming-specific networking) is the next and final new series.