In the spring of 2005, Linux kernel developers lost the tool that had kept the planet's most distributed software project afloat for three years. BitKeeper — a proprietary version control system — vanished from their hands not because of technical failure, but because of a licensing conflict that forced Linus Torvalds to create Git in a matter of weeks. But this story isn't about lone genius — it's about how an architectural choice made under time pressure rewrote the rules of the game for millions of developers.
Before 2002, Linux kernel development relied on patches in email and tar archives. Linus Torvalds manually applied thousands of changes, filtering out broken ones, assembling them into releases. The project's scale — several thousand active participants, dozens of subsystems, parallel branches for stable and experimental versions — turned this model into a bottleneck. Centralized systems like CVS or Subversion didn't fit: they required a single server storing the complete history, with all commits passing through it. For a project where half the participants worked offline, on unstable connections, or behind corporate firewalls, this was a death sentence.
BitKeeper from BitMover (founded by Larry McVoy) offered a distributed model: each developer got a complete copy of the repository, could make commits locally, create branches, and merge changes without contacting a central server. The pull system — requesting changes from one tree into another — became the foundation of the workflow: subsystem maintainers collected patches, Linus pulled their trees into his own. This solved the scaling problem but created another: BitKeeper was a closed commercial product. The company provided the Linux community with a free license, but with strict conditions: no reverse engineering, mandatory publication of change logs on openlogging.org, use only in open projects.
The license was a time bomb. The open community depended on a tool whose source code it didn't control, and the company could change the terms at any moment. Some developers refused BitKeeper on principle — due to ideological concerns, because they worked on competing version control systems, or because they didn't want to agree to monitoring through openlogging.org. Richard Stallman publicly condemned the deal with BitMover: in his words, developers using the free tool were paying with their freedom. But Linus made the compromise: an alternative that would work for Linux simply didn't exist.
Andrew Tridgell — an Australian programmer, author of Samba — decided in spring 2005 to study BitKeeper's network protocol. He wasn't hacking the system or stealing source code: he was connecting to public servers and observing what packets they sent, trying to reproduce the logic of how it worked. The goal was academic: understand how distributed synchronization worked, and possibly create a compatible client. Tridgell didn't even use BitKeeper himself — he hadn't accepted the license. But Larry McVoy interpreted this as reverse engineering and a violation of the terms under which the tool was provided to the Linux community.
April 6, 2005, BitMover announced that the free license was revoked. Formally, the conflict concerned Tridgell, but the blow hit the entire project. Linux developers lost access not only to the current version of BitKeeper, but also to the change history that had accumulated over three years in a proprietary format. The data could be exported, but that required time and tools. Most importantly — a replacement was needed immediately: kernel development couldn't stop for weeks or months while the community chose a new system and learned to use it.
Linus tried to negotiate. He proposed compromises to McVoy, tried to separate Tridgell's actions from the project's needs. Nothing worked. McVoy believed the Linux community had violated a gentlemen's agreement and wasn't going to make concessions. In a sense, this was an honest position: BitMover had given the tool away for free, but in exchange for trust, and that trust had been undermined. But for Linus, it meant thousands of developers were left without a workflow at the most inconvenient moment — right before another major release.
Legend has it that Linus "got angry and wrote Git over a weekend." Reality is more prosaic: he started April 3, and April 7, 2005, the first commit to Git was made by Git itself — the system was already self-hosting; April 16, kernel development was already happening in the new system. Ten days — but not for a finished product, but for a working prototype that could do one thing: manage Linux source code without a central server and without losing history.
Torvalds didn't start from scratch. He'd worked with BitKeeper for three years and understood which architectural decisions worked there: distribution, cheap branches, snapshots instead of deltas. He studied Monotone — another distributed version control system that used cryptographic hashes to identify objects. Monotone was slow and written in a language Linus didn't like, but the idea of content-addressable storage — where each object is identified by a SHA-1 hash of its contents — seemed right to him. This provided integrity, corruption detection, natural deduplication.
Git was built as a set of scripts in Perl and Bash on top of low-level commands in C. Early versions were rough, commands were called git-update-cache, git-write-tree, git-commit-tree — without a unified interface, without friendliness to newcomers. But they worked. Files and directory trees were stored as immutable blob objects, commits referenced trees and parent commits, all of this formed a graph that could be traversed, compared, merged. There was no central server: each repository contained the complete history, synchronization came down to exchanging objects between nodes. Branches were just pointers to commits — creating a new branch cost writing 41 bytes to a file.
April 7, Linus released the first Git tarball 0.01 — and the community started using it. Not because Git was convenient or understandable, but because it allowed work to continue. The first months were chaos: the interface changed almost daily, there was almost no documentation, bugs emerged in batches. But the basic model proved robust: object graph, hash-based addressing, local history, distributed replicas. These were the skeleton bones that later grew muscles.
By summer 2005, Git was handling the Linux kernel but remained a tool for the initiated. Commands were low-level, errors cryptic, the workflow required understanding of internal workings. July 26, Linus handed maintainership to Junio Hamano — a Japanese developer who had been actively patching Git from the early days. Hamano did what Linus had neither time nor interest for: turned a set of hacker scripts into a maintainable project.
Hamano standardized the interface, introduced porcelain commands — high-level commands like git commit, git merge, git branch — that hid the plumbing. He wrote documentation, packaged releases, established a patch acceptance process. Git began moving beyond the kernel: other open projects tried it, found it convenient, switched over. But mass adoption hadn't happened yet. For most programmers, Git remained exotic: CVS and Subversion were familiar, understandable, with GUI clients and integrations. The distributed model seemed excessive for teams working in the same office and committing to a shared server.
The turning point came not from technology, but from a platform. In 2008, three programmers from San Francisco — Tom Preston-Werner, Chris Wanstrath, and PJ Hyett — launched GitHub. They didn't invent Git hosting: such services already existed, like repo.or.cz. They did something else: turned Git into a social network for code. User profiles, activity feeds, the ability to fork someone else's project with one click, send a pull request — a proposal for changes — through a web interface. This lowered the barrier to entry: no need to configure SSH keys, figure out access rights, negotiate with repository owners. Anyone could clone a project, make changes, and propose them back.
The pull request became not just a technical operation, but a social ritual. Code review, discussion in comments, iterative fixes, merging into the main branch — all of this happened publicly, with history, with context. GitHub added reputation mechanisms: number of stars on a project, number of forks, contributor activity. Open code turned into a meritocracy where contributions were visible and measurable. By the end of 2013, GitHub hosted more than 10 million repositories — double the number from a year earlier. Git stopped being a tool for kernel hackers and became an industry standard.
Linus designed Git for Linux's needs: a massive codebase, thousands of participants, parallel branches, merges from dozens of sources. But the architecture proved universal. Content-addressable storage meant identical files occupied space only once — even if they appeared in dozens of branches. Snapshots instead of deltas simplified restoring any version: no need to apply a chain of changes, just read the object tree at commit time. Cheap branches turned branching from a rare operation into an everyday one: create a feature branch, experiment, merge or discard — all of this cost seconds.
Distribution solved a problem Linus hadn't thought about: working in the cloud. When development moved to CI/CD pipelines, Git proved the ideal tool. Each build cloned the repository, ran tests, built artifacts — and all of this locally, without dependence on a central server. Jenkins, GitLab CI, GitHub Actions are built around Git repositories as the source of truth. Deployment via Git tags, rollback via git revert, versioning infrastructure as code in the same repositories — all of this exploits an architecture designed for the problem of "thousands of developers without a shared server."
GitLab, launched in 2011, added self-hosting: companies could deploy a GitHub analog inside their infrastructure, behind a firewall. This removed the last barrier to corporate adoption: if GitHub was a social network for open code, GitLab became a tool for closed projects. By the mid-2010s, Git had displaced Subversion and Mercurial from most niches. Even projects that had been on CVS for decades — like FreeBSD or NetBSD — began migrating.
The legend of "the genius who created all of modern development over a weekend" is beautiful but false. Linus was solving a concrete problem: April 6, 2005, Linux lost its tool, and ten days later a replacement was needed. He chose the distributed model not from foreseeing the future, but because it was the only thing that worked for the kernel. He took cryptographic hashes from Monotone, snapshots from BitKeeper experience, cheap branches from understanding that subsystem maintainers had to work independently.
Git won because it appeared at the right moment. 2005 was the beginning of the era of open source as mainstream. Projects like Firefox, OpenOffice, Ubuntu were attracting thousands of participants. Centralized systems couldn't cope, proprietary solutions were ideologically off-putting. Git was open, fast, scalable — and already battle-tested on the planet's largest open project. When GitHub in 2008 made it accessible, the industry was ready.
But most importantly — Git proved flexible enough to survive beyond its niche. The model designed for distributed teams worked for centralized ones too. The architecture optimized for huge codebases handled small ones. The interface, initially cryptic, evolved into something you could teach to juniors. This isn't genius, this is luck: the right set of compromises made under time pressure that later proved resilient to change.
The BitKeeper conflict could have ended differently. Linus could have chosen Mercurial — another distributed system that appeared almost simultaneously with Git and was more user-friendly. Or the community could have stayed on email patches for a few more years until someone else created an analog. But history unfolded this way: April 3, started writing code, April 16, migrated the kernel, July 26, handed over maintainership, and three years later Git became the foundation of GitHub. Not a plan, not providence — just a series of decisions under pressure of circumstances that accidentally assembled into a system that outlived its creator and its original purpose.