History of Git
Git was created by Linus Torvalds — the same person who created Linux — in April 2005. It was born out of frustration, written in roughly ten days, and has since become the de-facto standard for version control on the planet. The story of how it came to exist is a useful one because it explains why Git looks and behaves the way it does today.
Before Git: the BitKeeper era (1991–2005)
From 1991 until 2002, Linux kernel changes were sent around as patches over email. Linus would receive thousands of patches, apply them manually, test them, and integrate them. That worked when the project was small. By the early 2000s the kernel had thousands of contributors and email-based patching had become a serious bottleneck.
In 2002 the kernel moved to a proprietary distributed VCS called BitKeeper. BitKeeper was excellent for its time — and crucially, free for open-source use. For three years the Linux community used it happily, and Linus picked up a strong taste for what a good distributed VCS could feel like: fast, local, branch-friendly.
The break with BitKeeper (April 2005)
In April 2005 the relationship between the Linux community and BitMover (BitKeeper’s company) collapsed. BitMover withdrew the free license over a dispute about reverse-engineering of the BitKeeper protocol. Suddenly the world’s largest open-source project had no version control system. Worse, none of the existing alternatives — CVS, Subversion, Monotone, Arch, Darcs — matched what Linus wanted.
So he wrote his own. The requirements were brutal:
Speed. It had to be fast enough to handle the entire Linux kernel — hundreds of megabytes, tens of thousands of files, decades of history.
Distributed. Every developer must have a complete copy of the history. No central server should be required for daily work.
Strong against corruption. Every object should be content-addressed by a cryptographic hash, so silent data corruption is impossible.
Designed for branching and merging. Branches should be cheap and merging should be reliable, because that is how thousands of contributors work in parallel.
Simple data model. The internals should be a small set of well-defined object types — easy to back up, easy to reason about, easy to repair.
Ten days of furious coding
Linus started writing Git on 3 April 2005. By 7 April he had a working prototype. On 17 April he made Git itself self-hosting — Git was now using Git for its own development. By June 2005 the entire Linux kernel was running on Git. From idea to managing the largest open-source project in the world: about two months.
From Linus to Junio Hamano
Linus maintained Git for only a few months. On 26 July 2005 he handed over maintenance to Junio Hamano, who is still the lead maintainer today. Junio coordinates releases, reviews patches sent to the public mailing list, and shepherds the project with the same patient discipline he has shown for nearly two decades.
Key milestones
2005 — April: Git is created in 10 days by Linus Torvalds.
2005 — July: Maintenance handed over to Junio Hamano.
2005 — December: Git 1.0 released.
2008 — April: GitHub launches, giving Git a friendly web home and dramatically accelerating its adoption.
2010 — August: Git 1.7.2 introduces the
--no-ffand improves merging UX.2014: Git overtakes Subversion as the most popular VCS on Stack Overflow’s developer survey.
2015 — January: Git LFS (Large File Storage) is released by GitHub for binary assets.
2018 — June: Microsoft acquires GitHub for $7.5 billion — a strong signal of Git’s central importance.
2019 — August: Git 2.23 introduces
git switchandgit restoreto replace the dual-purposegit checkout.2020 — October: GitHub renames the default branch from
mastertomain. The rest of the industry follows.2021 — March: Git 2.31 begins moving toward SHA-256 hashes as an alternative to SHA-1.
Today: Git is used by over 90% of professional developers (Stack Overflow Developer Survey, 2023). The Linux kernel still runs on it. So does almost everything else.
Why this history matters when you use Git
Git was designed to handle the Linux kernel. That is why it is so fast even on huge repositories — and why most developers will never see it slow down on their projects.
It was built for distributed work. There is no “server mode” bolted on later — the design assumes every clone is a full peer. This is why you can work offline.
It uses cryptographic hashes for everything. That is not a feature added for security; it is the storage model itself. This is why
git logshows long hex strings.It exposes its plumbing. Many Git commands you will never use (
git update-index,git hash-object) exist because Git was originally a set of low-level scripts. The friendly commands you do use (git add,git commit) are wrappers on top.It is maintained by volunteers via email and patches. That community style is the same one that built Linux — slow, careful, and conservative about changes.
Understanding where Git came from explains many of its quirks. It was written quickly, by one strong-opinioned engineer, for one specific extreme use case. Two decades later that same tool — barely changed at its core — runs the software industry.