Before Git, many teams used centralized systems such as CVS and Subversion: one server held the canonical history, and developers checked out working copies. That model worked until a project the size of the Linux kernel needed something faster, distributed, and free to use without a proprietary license. Git was built for that moment and became the default tool for open source and most commercial software.
BitKeeper and the break that forced a rewrite
Through the early 2000s the Linux kernel used BitKeeper, a proprietary distributed VCS. Andrew Tridgell’s reverse-engineering work led BitMover to withdraw the free license for kernel development in 2005. The kernel community had days, not years, to replace its workflow.
Linus Torvalds announced Git in April 2005. The first commits were self-hosting: Git was written in C and used Git to track Git. The name is British slang for an unpleasant person—Torvalds joked that he names his tools after himself.
Design goals that still define Git
Torvalds optimized for kernel-scale problems. Those choices explain Git’s behavior today:
| Goal | What it means in practice |
|---|---|
| Speed | Most operations are local. Commits, diffs, and log walks avoid the network unless you fetch or push. |
| Distributed | Every clone is a full copy of history. You can commit, branch, and merge offline. |
| Integrity | Objects are content-addressed (originally SHA-1, now SHA-256 where enabled). Corruption is detectable. |
| Non-linear history | Cheap branches and merges support parallel work instead of a single linear trunk. |
Git was not designed to be gentle. It was designed to be correct and fast for experts. Usability improvements (better defaults, main instead of master, clearer messages) came later through the community and hosting platforms.
Junio Hamano and the stable maintainer
Torvalds remains involved, but Junio Hamano has been the primary Git maintainer since 2005, merging contributions and cutting releases. Git’s release cadence and backward compatibility expectations mirror the kernel’s: scripts and CI depend on stable CLI behavior.
GitHub and the social layer
GitHub launched in 2008 (built on Git, not identical to it). It added pull requests, code review UI, issues, and social discovery. Git stores objects and refs; GitHub stores permissions, discussions, and automation. That split matters when you work offline or move between hosts: the .git directory travels; the platform features do not.
Other hosts (GitLab, Bitbucket, self-hosted Gitea) wrap the same Git protocol with different review and CI models. The history in your repository stays portable.
Default branch names and inclusivity
For years the default branch was master. GitHub, GitLab, and Git itself moved toward main as the default name for new repositories. Existing repos keep their branch names until you rename them; tooling and docs increasingly assume main.
SHA-1, SHA-256, and object identity
Git identifies blobs, trees, and commits by cryptographic hash. SHA-1 was the original algorithm. Collision attacks against SHA-1 motivated SHA-256 support (objectFormat in newer repositories). Mixed fleets may still see SHA-1 repos; migration is a deliberate admin task, not something every developer toggles daily.
Milestones at a glance
| Year | Milestone |
|---|---|
| 2005 | Git announced; Linux kernel adopts it |
| 2008 | GitHub founded |
| 2010s | Git becomes default for new projects; DVCS training mainstream |
| 2020 | Git 2.28+ can default init branch to main |
| 2020s | SHA-256 repositories gain tooling support |
What this history explains for developers
Three facts clarify many day-to-day Git surprises:
Git is local-first. commit, branch, and merge do not require a server. Network commands (fetch, push) synchronize remotes you configure yourself.
History is a graph, not a tape. Branches are pointers into a DAG of commits. “Rewriting history” changes which commits are reachable, not whether old objects instantly vanish.
Hosting is optional. You can email patches, use internal servers, or GitHub. The same objects and refs underlie all of them.
Next: How Git works.
Check your understanding
Question 1 of 8
0 of 8 checked