Two decades of Git: A conversation with creator Linus Torvalds
Analysis of the evolution of Git: from a “tool for yourself” in 2005 to the de facto standard for source code management.
Source
Two decades of Git
Interview with Linus Torvalds about the creation and evolution of Git.
Guests and regalia
What is the film about?
In April 2005, Linus Torvalds made the first version of Git in about 10 days after losing BitKeeper in a Linux process. He initially wrote the tool “for himself” and did not try to repeat the UX of old VCS.
Already in the fall of 2005, support passed to Junio C Hamano, and then Git grew into the dominant platform for collaborative development: the architecture turned out to be stable, and the ecosystem gradually closed corporate and product extensions.
Git Key Ideas
Distributed model as default
Each clone is a full-fledged repository. This is a local-first approach that removes the dependence on a central server for daily development.
Speed as an architectural requirement
Git was designed for the Linux kernel scale: operations with patches, branches and merges should be fast even on large histories.
Object-level data integrity
Commits and objects are linked by cryptographic hashes, which increases the reliability of the history and reduces the risk of unnoticed data corruption.
Minimalistic core and long-lived evolution
The basic concepts remained stable for decades: complexity grew through tooling around the core, rather than through breaking the model.
What does this mean in practice?
For engineers
- The tool wins when it relieves pain on a real scale, and not just in a demo scenario.
- Local autonomy speeds up teams and reduces operational friction.
- Strong basic invariants (like the integrity of history) pay off over the long term.
- The ecosystem can close use-cases that the authors did not initially think about.
For technical leaders
- Give engineers space to solve fundamental problems, even if the solution looks crude at first.
- Evaluate tools by resilience, scale, and team speed, not by trend.
- An open development model creates a stable platform and reduces vendor lock-in.
- Critical internal tools should be designed as a product, not as a temporary workaround.