This article is based on reporting originally published on devops.com in April 2020, marking Git’s 15th anniversary.
From Insult to Industry Standard
Git, the distributed version control system that has underpinned a generation of DevOps tooling and practice, turned 15 in April 2020. Created by Linus Torvalds — best known as the originator of the Linux kernel — Git was named with characteristic irreverence. Torvalds and the broader Linux community jokingly referred to it as “that stupid content tracker,” and the word git itself is British slang for a contemptible or foolish person. The name stuck.
Fifteen years later, the joke has aged rather poorly: Git is now one of the most widely adopted and consequential open source projects in computing history.
A Brief History of Git
Torvalds created Git in 2005, initially to manage the Linux kernel source code after a licensing dispute ended the project’s use of the proprietary BitKeeper system. The goals were clear from the start: speed, strong support for non-linear development (branching and merging), full distribution, and the ability to handle large projects efficiently.
Shortly after its creation, day-to-day stewardship of the project passed to Junio Hamano, a software engineer who has led Git development for the full 15 years since. Hamano works at Google. His long-running maintenance of the project is widely credited with providing the stability and discipline that allowed Git to mature from a Linux-centric tool into a universal standard.
Why Git Won
Non-linear version control was not a new concept when Git launched in 2005 — other systems already supported branching. What set Git apart was the combination of:
- Speed: Most operations are local, making common commands nearly instantaneous compared to centralized systems.
- Cheap, fast branching and merging: Creating a branch in Git is a trivial operation, which encouraged experimentation and short-lived feature branches — a workflow that maps directly onto modern CI/CD pipelines.
- Distributed architecture: Every working copy is a full repository with complete history, eliminating single points of failure and enabling offline work.
- Visualizable non-linear history: Git’s directed acyclic graph (DAG) model makes it possible to reason about complex development histories in a way that linear systems cannot match.
These properties aligned naturally with the principles that would later crystallize into DevOps: automation, collaboration, rapid iteration, and a focus on flow. Git became the connective tissue between source code, CI systems, deployment pipelines, and infrastructure-as-code repositories.
“Git is an essential part of everything we do. It’s the single source of truth.”
Pratik Wadher, Vice President, Intuit
Git’s Place Alongside SQL and Linux
By 2020, organizations across every industry were running DevOps initiatives that depended on Git. GitHub, GitLab, Bitbucket, and related platforms had grown into a multi-billion-dollar segment of the IT industry. Platforms compete on features built around Git — merge request workflows, code review, CI integration, security scanning — but the underlying protocol remains the shared foundation.
“The interesting thing about Git is that it has had real staying power. In terms of industry standards, Git can take its place alongside SQL and Linux in terms of impact.”
Kelly Stirman, Vice President of Product Strategy and Marketing, GitHub
That comparison is worth sitting with. SQL survived decades of competing query languages and NoSQL movements. Linux displaced proprietary Unix variants and now runs the majority of the world’s servers. Git appears to be following a similar trajectory in the version control space.
Ongoing Innovation: Partial Clones and Large File Support
Despite its maturity, Git’s pace of development remained active at the 15-year mark. A notable area of collaborative work involved partial clone capability — a feature that GitLab, GitHub, Microsoft, and Google contributed to together. Rather than requiring developers to clone every file in a repository, partial clones allow a working copy to be initialized with only the objects actually needed for a given task, fetching additional data on demand.
This is particularly relevant for:
- Large monorepos where full clones are prohibitively slow or storage-intensive.
- Game development pipelines that routinely involve binary assets (textures, audio, 3D models) many gigabytes in size.
- Geographically distributed teams for whom cloning over wide-area networks is a recurring bottleneck.
“It will enable new use cases.”
Brendan O’Leary, Senior Developer Evangelist, GitLab
At the time of writing (April 2020), partial clone support was available as an experimental feature in both GitHub and GitLab. Developers working with very large repositories should consult current documentation for each platform to understand what is now generally available.
Git as the Default — Not a Choice
Perhaps the clearest sign of Git’s dominance is that, for most developers entering the industry today, using Git is not a deliberate choice — it is simply how software is managed.
“Git is now the default way to manage source code. Ten years ago that was not the case.”
François Dechery, Chief Strategy Officer, CloudBees
This shift has profound implications for DevOps adoption. When Git is assumed, practices built on top of it — feature branching, pull/merge request workflows, GitOps, trunk-based development — become easier to introduce because teams are not simultaneously learning a new tool and a new methodology.
What Comes Next
Looking beyond the 15-year milestone, several trends point to continued evolution around Git rather than replacement of it:
- GitOps: Using Git repositories as the source of truth for infrastructure and application state, with automated reconciliation loops keeping live environments in sync with declared configuration.
- AI-assisted development: Code generation, review, and suggestion tools that integrate directly into Git-based pull request workflows.
- DevSecOps integration: Security scanning, secret detection, and policy enforcement embedded into Git-hosted CI pipelines rather than applied as a post-deployment afterthought.
- Scalability improvements: Continued work on sparse checkout, partial clones, commit graph acceleration, and other features to keep Git performant as repositories grow.
“It’s been quite a journey. No one really knew 15 years ago just how big an impact the repository would have on software development.”
Ido Green, Vice President of Technology, JFrog
Key Takeaways
- Git was created by Linus Torvalds in 2005 and has been maintained by Junio Hamano ever since.
- Its distributed model, fast branching, and non-linear history support made it a natural fit for DevOps workflows.
- Git now underpins a multi-billion-dollar platform ecosystem spanning GitHub, GitLab, Bitbucket, and beyond.
- Active development — including partial clone support contributed collaboratively by major vendors — shows the project is far from stagnant.
- For most engineers entering the field today, Git is simply assumed — a sign of how completely it has displaced alternatives.