Git's Origin: The Linux Kernel Crisis and a New Distributed History

Git did not begin as a polished general-purpose product or a plan to displace every version-control system. It began in April 2005, when the Linux kernel maintainers needed a replacement for the source-control workflow they had used for several years. The resulting tool was shaped by the scale and social structure of that project: many contributors, independent subsystem trees, frequent integration, and a maintainer who could not serialize every proposed change through one shared writable server.

That origin explains both Git’s strengths and its unusual vocabulary. A commit is not merely a patch waiting in a central queue. It is a named point in a graph of snapshots; branches are references that can move; and repositories can exchange history without asking one server to own every change. These mechanisms grew out of an urgent engineering constraint, then matured through a project that needed to coordinate a large, distributed community.

The workflow before Git

For much of the Linux kernel’s early development, contributors sent patches and archived source snapshots to maintainers. This process could work, but each release cycle involved collecting changes, determining which patch applied to which baseline, resolving conflicts, and preserving the relationships between accepted work. As the contributor and subsystem network grew, the cost of coordinating changes became as important as editing the code itself.

In 2002, the kernel project began using BitKeeper, a proprietary distributed version-control system. The Git project’s own history describes BitKeeper as useful for kernel development and records that the relationship between the community and BitMover broke down in 2005, after which the no-cost use of BitKeeper was withdrawn. That phrasing is important: the event was not that distributed version control had failed technically. The kernel had relied on it, and losing access created a practical need for a replacement that could preserve the workflow’s useful properties.

Accounts often reduce the story to one dispute or one personality. The primary record supports a narrower conclusion: the kernel project had an established tool, its licensing arrangement ended, and the maintainers needed a replacement quickly. Git’s initial design therefore addressed a real operating constraint rather than a hypothetical comparison chart.

A first implementation in days, not a finished product

The Git repository records an initial revision by Linus Torvalds on April 7, 2005. Its commit message called the program “the information manager from hell,” a joke that captures how experimental the first implementation was. The commit is a more precise historical marker than later anniversary retellings because it preserves the actual source tree and author metadata.

The first Git tool and the first Git-managed Linux release are separate events. On April 16, Torvalds imported the Linux 2.6.12-rc2 source into a Git repository. That commit explicitly said it did not import the complete earlier kernel history; at the time, the repository was meant to establish a workable starting point, not reconstruct every older change. On April 20, when announcing Linux 2.6.12-rc3 to the kernel mailing list, Torvalds described it as the first release built completely with Git. The project had moved from a new tool to a real release workflow in less than three weeks.

This timeline corrects two common compressions. Git’s first source commit was not itself the first Linux release managed by Git, and the early Linux repository did not contain all historical kernel development. The archive lets readers inspect those milestones directly instead of treating the date of the first commit, the initial source import, and the first Git-built release as interchangeable.

The object model makes history a graph

Git’s core model is a content-addressed object database. A blob records file content, a tree records names and links to blobs or other trees, and a commit identifies a top-level tree plus parent commit references and metadata. Repeating unchanged content can reuse an existing object rather than copying a full working tree into every historical point. A merge commit can name more than one parent, so the repository represents parallel lines of work and their integration as a directed acyclic graph.

commit C
  tree: T2
  parents: P1, P2

tree T2
  src/main.c -> blob B7
  docs/       -> tree T3

This description is about Git’s object relationships, not a claim that every file is stored as a complete independent copy. The logical snapshot points to objects; storage packing and delta compression can optimize how those objects occupy disk without changing the history graph operators inspect. That separation helped Git make snapshots simple to reason about while allowing the repository format and storage strategies to evolve.

Branches are references to commits, not mutable containers holding a private copy of a directory. Moving a branch reference after a commit advances the name to a new point in the graph. A tag provides a name intended to identify a particular point or object. The graph and references are distinct: commits describe history, while branch names help people select and coordinate where work continues.

Why distribution mattered to kernel maintainers

A normal full clone contains repository history and can create new commits locally; shallow and partial clones intentionally limit what history or objects are present. Contributors can build a proposed line of work without writing to a central repository; maintainers can inspect and integrate that work through merges or other reviewed workflows. A remote is a convenient exchange point, not a database authority required for every local operation. This is why Git is distributed even when a project chooses one canonical public repository and a maintainer controls what enters it.

The distinction matters. Distributed storage does not mean that every contributor has equal approval rights, nor does Git automatically decide which change is correct. Kernel maintainers still review patches and manage subsystem ownership. Git changes the mechanics of recording, comparing, and transferring work; project policy determines who accepts it.

For the kernel, a graph could record parallel branches from subsystem maintainers and later joins into a release tree. The history described not only the final file contents but also the relationships between integration points. This matched a development process already organized around maintainers and patch series better than a single shared lock or one global sequence of edits.

From emergency replacement to project stewardship

The early implementation prioritized the use case immediately in front of it: handle the Linux kernel’s large source tree and many parallel branches quickly, keep the design compact, and support distributed work. The Git project’s published history lists speed, simple design, strong non-linear development, distribution, and large-project efficiency among the initial goals. These were engineering priorities, not proof that the first version already had today’s command set, interfaces, or interoperability.

The first release milestone also exposed the ordinary work of turning a storage engine into a collaborative tool. The April 20 kernel announcement noted that release tooling and ChangeLog generation were still being adapted; some of the new release’s supporting scripts were manual or ad hoc. A working commit graph was necessary, but maintainers also needed review conventions, import/export paths, documentation, and reliable release procedures.

Git then became a project in its own right. Its object model remained recognizable as commands and interfaces grew around it. The system’s later popularity should not be projected backward as an inevitable outcome: in April 2005 the immediate test was whether it could replace an operational dependency and carry actual kernel development.

What the origin explains, and what it does not

Git’s history helps explain why it treats local commits, branch references, and graph merges as ordinary operations rather than exceptional server transactions. It also explains why the first audience was comfortable with command-line tooling and repository-level concepts. But origin is not destiny: modern teams use Git through graphical clients, hosting platforms, code review systems, and automated pipelines that were not part of the initial kernel replacement.

The most accurate short version is not that Git was invented because centralized version control was universally impossible. It was built for a particular collaboration problem after a licensing arrangement ended, and the distributed model already in use by the kernel proved valuable enough to reproduce. The first source commit, the kernel snapshot import, and the first release built with Git are independently documented milestones. Together they show an emergency tool becoming production infrastructure through iterative engineering, rather than a complete version-control philosophy appearing fully formed in a single afternoon.

Related:

Sources: