How did the man who created Git make Git without Git?

Imagine you’re tasked with inventing a hammer, but you don’t have any tools to build it. That’s roughly the situation Linus Torvalds faced in April 2005 when he set out to create Git, the version control system that now underpins much of modern software development. The Linux kernel team had just lost access to BitKeeper, their previous tool, and Linus—fed up with clunky alternatives—decided to roll his own. But how do you code a version control system without one to manage the code? The answer lies in a mix of raw skill, minimalism, and a clever bootstrap.

Before Git, the Linux kernel’s development was a patchwork mess. Early on, developers swapped tarballs and emailed patches—think of it like passing notes in class, but for code. BitKeeper brought some order, but when its free version vanished due to licensing drama, Linus said, “Enough.” He started from scratch, armed with nothing but a text editor (probably Vim), the C programming language, and a weekend’s worth of determination.

The trick was starting small. Linus didn’t need a full-blown system out of the gate—he just needed the bare bones: blobs to store file contents, trees for directory structures, and commits to snapshot changes. He banged this out in a single directory on his machine, likely keeping manual backups or duplicate folders. No fancy repository existed yet because Git was the repository-to-be. By April 7, 2005—mere days after starting—he had a working prototype. It wasn’t pretty, but it could track files and log commits. That’s when the magic happened: Git started managing its own development.

This self-hosting pivot was the key. Once Git could commit, Linus used it to track Git’s own source code. He announced it to the Linux kernel mailing list, and the first real Git repository was born—built by the tool it contained. Early contributors like Junio Hamano (who’d later take over as maintainer) joined in, initially pulling code via patches or tarballs. But they quickly switched to Git as it stabilized, turning a solo hack into a collaborative effort.

The process wasn’t glamorous. Those first days involved hand-stitched updates and emailed diffs—chaotic, but effective for a small, skilled crew. Linus’s speed and pragmatism drove it home: he didn’t need a perfect tool to start; he just needed one that worked well enough to grow itself. By April’s end, Git was a functional DVCS, ready to scale.

So, how did they code Git without Git? They didn’t—not at first. They leaned on raw files, quick coding, and a leap of faith until Git could lift itself off the ground. It’s a classic bootstrap story: build the minimum, use it to build more, and let it run wild. Today, Git’s everywhere, but its origin is a reminder that even the slickest tools start messy.