The Ten-Day Project That Took Over Software: The Real Story of Git

Open a job listing for almost any software role in Dubai, Abu Dhabi, or anywhere else in the world, and one requirement shows up more reliably than any programming language: "experience with Git." It is the invisible plumbing behind nearly all modern software development — the system that lets teams of developers, scattered across time zones, edit the same codebase without destroying each other's work.

What's less well known is that Git wasn't built by a company, a committee, or a startup chasing venture funding. It was built in a hurry, by one furious programmer, because a corporate dispute had just taken away the tool his entire project depended on.

A Kernel With No Version Control

By the early 2000s, the Linux kernel — the open-source core that powers everything from Android phones to most of the world's servers — had a problem. Thousands of developers around the world were contributing code to it, but there was no good system for merging all those contributions together. For a while, Linus Torvalds, the kernel's creator, managed contributions essentially by hand, applying patches people emailed him.

In 2002, the kernel team adopted BitKeeper, a proprietary distributed version control system, to manage this chaos. BitKeeper's maker, BitMover, let the Linux project use it for free — an arrangement that was unusual for a commercial tool, and which irritated some free-software purists from the start.

That arrangement fell apart in April 2005. According to accounts published at the time, including a detailed retrospective in Linux Journal, a kernel developer named Andrew Tridgell had been experimenting with reverse-engineering BitKeeper's network protocol. BitMover's CEO, Larry McVoy, had warned that any such attempt would end the free license for Linux — and when it happened, he followed through. The kernel project's access to BitKeeper was pulled.

Ten Days, One Furious Programmer

Torvalds needed a replacement, and needed it fast — the kernel had thousands of contributors and no functioning way to track changes. He evaluated the existing free alternatives and reportedly found none of them fast or robust enough for a project of Linux's scale, particularly for a fully distributed model where every contributor's copy of the repository is a complete, independent copy of the project's history, not just a thin client talking to a central server.

So he wrote his own. Development began on April 3, 2005. The project was announced to the kernel mailing list on April 6, and by April 7 — the date Git itself usually cites as its birthday — the tool was "self-hosting,": its own source code was being tracked using Git itself. Torvalds has described the early work as consuming roughly ten days of concentrated effort before it was usable enough to manage real kernel development.

The name, by Torvalds' own famously self-deprecating explanation, is British slang for an unpleasant person — he said he names his projects after himself, and depending on the day, "git" fit.

Torvalds didn't intend to run the project forever. Within a few months he handed day-to-day maintenance to Junio Hamano, a contributor who had gotten involved almost immediately after the April 2005 announcement. Hamano formally took over as Git's maintainer that July and remains its lead maintainer two decades later, overseeing a tool now used by what is almost certainly tens of millions of developers.

Why Distributed Was the Whole Point

The technical decision that made Git different from the version control tools that came before it — including BitKeeper itself, and especially centralized systems like Subversion and CVS, which were dominant at the time — was its distributed architecture. In a centralized system, there is one master copy of a project's history, held on a central server, and developers check out and submit changes to it. If that server goes down, or if a developer is offline, work largely stops.

In Git, every single clone of a repository contains the entire project history: every commit, every branch, every tag, going back to the first one. This sounds like a minor technical detail, but it has enormous practical consequences. Developers can commit, branch, and review history without a network connection. There is no single point of failure. And because branching and merging are cheap, Git made it practical for huge numbers of contributors to experiment in parallel and merge their work back together — exactly the problem that had made managing the Linux kernel so painful in the first place.

From Mailing-List Patches to GitHub

Git itself remained a command-line tool with a notoriously steep learning curve, and for a few years it was mostly the preserve of kernel developers and other open-source projects. That changed with the arrival of hosting platforms built around it.

GitHub, founded by Tom Preston-Werner, Chris Wanstrath, P. J. Hyett, and Scott Chacon, launched publicly in April 2008, built entirely around Git as its underlying engine. It added something Git itself didn't provide: a web interface, social features like following projects and developers, and crucially, "pull requests" — a lightweight way to propose and review changes that turned Git from a developer's personal tool into a collaboration platform. GitLab and Bitbucket followed with similar models.

GitHub grew enormous enough that Microsoft acquired it in 2018 for $7.5 billion, in a deal that closed that October with former GitHub CEO Chris Wanstrath moving into a technical fellow role at Microsoft and Xamarin founder Nat Friedman taking over as CEO. The acquisition drew some unease from open-source advocates wary of a single company controlling the dominant hosting platform for Git — concerns Microsoft sought to address by promising GitHub would keep operating independently.

An Accidental Standard

What makes Git's story unusual is that it was never pitched as a product. It solved one team's very specific, very urgent problem, and the solution happened to be general enough that it eventually displaced every serious competitor. Subversion, CVS, Perforce, and Mercurial all still exist in pockets, but Git is now the default assumption baked into almost every developer tool, CI/CD pipeline, and coding bootcamp curriculum on the planet — including the growing wave of AI coding assistants that read and write to Git repositories as a matter of course.

Two decades on, the tool born out of a licensing dispute and ten days of frustrated coding has become something close to universal infrastructure: unglamorous, largely invisible to end users, and almost impossible to build modern software without.

Sources: Linux Journal's retrospective on Git's origins; GitHub's 15th-anniversary interview with Git maintainer Junio Hamano; Wikipedia's documented timeline of Git and GitHub; contemporaneous reporting on Microsoft's 2018 GitHub acquisition (TechRadar, The Next Web).