Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Git Becomes 15: Q&A with GitHub and GitLab

Git Becomes 15: Q&A with GitHub and GitLab

This item in japanese


On April 7, 2005, exactly 15 years ago, Git reached a sufficient maturity state to be self-hosting, meaning Git itself could be used to commit a part of its code. Today, Git has become one of the most widely adopted development tools and has changed the way developers manage their code. InfoQ has taken the chance to talk about Git's significance with GitHub's distinguished software engineer Jeff King and GitLab's senior developer evangelist Brendan O'Leary.

Git was born in an effort to put an end to the Linux kernel SCM saga by Linux creator and maintainer Linus Torvalds, who went on a personal journey to write a replacement for Linux original SCM tool, BitKeeper. As Torvalds himself explained, their experience with BitKeeper was an important one to set the overall goals for Git:

One impact BK has had is to very fundamentally make us (and me in particular) change how we do things. That ranges from the fine-grained changeset tracking to just how I ended up trusting submaintainers with much bigger things, and not having to work on a patch-by-patch basis any more. So the three years with BK are definitely not wasted: I'm convinced it caused us to do things in better ways, and one of the things I'm looking at is to make sure that those things continue to work.

Git took Torvalds an incredibly small amount of time to be written. He started working on it on April 3, 2005, creating the first commits "by hand", until it became ready for prime time shortly after that, first with its own first commit and then with Linux's first Git commit:

The first version of git was just ~1300 lines of code, and I have reason to believe that I started it at or around April 3rd. The reason: I made the last BK release on that day, and I also remember aiming for having something usable in two weeks.

And hosting git itself was not that important for me - hosting the kernel was. And the first kernel commit was April 16 (with the first merges being a few days later). Which meshes with my "two week goal" recollection.

To better understand how Git changed the software world, InfoQ has taken the chance to talk about Git's significance with GitHub's distinguished software engineer Jeff King and GitLab's senior developer evangelist Brendan O'Leary.

InfoQ: By all counts, Git took the open-source world by storm since its inception in 2005, both within small shops and large companies. How do you explain that? Which Git features can account for its extensive adoption?

Jeff King: Git has had a huge impact on open-source software development because its decentralized nature puts the same tools in everyone's hands.

Git's data model has proved to be both fast and flexible. This has allowed projects of many different sizes and with different workflows to adopt it. It also was used by prominent projects early on: the Linux kernel and the Ruby language ecosystem. That gave it an instant user base and served as an endorsement to others in software development.

Brendan O'Leary: Before git, the vast majority of popular source code management tools were centralized. This meant that everyone had to connect to a central server to get any work done. Git brought to reality the ability to work on code in a distributed fashion, even with large codebases like the Linux kernel. This distributed nature was a critical part of enabling the open-source revolution we’ve seen over the last 15 years.

InfoQ: What is Git's “killer feature” in your opinion?

O'Leary: While it can be daunting to try and understand all the things git is doing internally, its killer feature is actually - believe it or not - its simplicity. Git does not presume a given workflow or a given set of external tools. Git focuses on the core-competence of tracking changes in the lightest way possible, enabling distributed source code management on a scale the world hadn’t seen before.

King: Anything related to software archaeology. When investigating a bug in Git, I often end up digging through the last 15 years of history to figure out why the code looks like it does. git blame (and especially the tig blame viewer), git bisect, git log -S are all indispensable parts of my toolbox.

InfoQ: How did Git change the way developers work and collaborate? What “development workflows” did Git enable that were previously not an easy option?

King:Git’s decentralized nature gave developers flexibility and transparency they previously did not have. Whether you're a regular contributor to a project or just looking at it for the first time, you have access to the same information and tools. Because the tools and data are local, developers can create their own individual workflows independent of each other.

O'Leary: Git enabled open-source software to become what it is today - a way to build software as we’d never dreamed of before. Prior to git, most source code management tools required a constant connection to the server in order to get work done. While that isn’t a major problem for large enterprises or projects with a set of core engineers, it makes it next to impossible for engineers to come in, contribute one feature and have it easily merged into the mainline. Git flipped this on its head by creating an open-source distributed source control management system, allowing developers across the world to collaborate on the same code base - enabling the explosion of open source software we’ve seen.

InfoQ: While Git's success in the open-source arena is visible to anyone, Git has been massively adopted for non open-source software development, too. What is your view about that? Is there any difference between open-source and non open-source software development with respect to the way a collaboration tool like Git is used?

O'Leary: Git has proven itself to be just as valuable in making closed-source or proprietary software as it has been for the open-source community it was designed for. Enterprises find themselves with many of the same challenges that open-source projects have: coordinating large groups of engineers toward a common goal of delivering better software faster. Git is built from the ground up to enable just that, and as more enterprises have distributed workforces across the world or working remotely, Git has delivered what those independent software vendors need as well. Look no further than Microsoft’s own adoption of Git for the Windows projects as proof that the source control system designed for the Linux kernel has universal appeal.

King: This is really about putting the same set of powerful, flexible tools in developers’ hands, regardless of whether they’re open-source contributors, hacking on a personal project, or working on proprietary software. Git’s decentralized core may be more appealing to open-source developers than enterprises, but no matter what group you fall into, Git makes it easy to document and collaborate on software development.

InfoQ: Do you see any relationship between Git's success and the existence of platforms like GitHub, GitLab, BitBucket, and many others that enable developer collaboration around code?

King: None of these platforms would exist without Git. Early on, there was endorsement for Git from different parts of the developer community (kernel, Ruby, etc.) that made it easier for Git to be top of mind for budding platforms like GitHub.

O'Leary: Git’s story is the ultimate success story of community-driven development. Many individuals collaborate and contribute ideas and features to Git’s codebase. This makes Git remarkably reliable, trustworthy, and a modern source code management system. Git’s usability and stability have created tremendous value - specifically in organizations like GitLab and GitHub who started as ways to host Git for your teams, and more broadly in enabling open-source’s massive growth which impacts all of the software written today.

Jeff King is a distinguished software engineer at GitHub, where he has worked since 2011 on scaling and maintaining Git's repository storage. He's been an active contributor to the Git project since 2006.

Brendan O'Leary is a senior developer evangelist at GitLab, the first single application for the DevSecOps lifecycle. He has a passion for software development and iterating on processes just as quickly as we iterate on code. Working with customers to deliver value is what drives O'Leary's passion for DevOps and smooth CI/CD implementation. O'Leary has worked with a wide range of customers - from the nation's top healthcare institutions to environmental services companies to the Department of Defense. Outside of work, you'll find O'Leary with 1 to 4 kids hanging off of him at any given time or occasionally finding a moment alone to build something in his workshop.

On the same topic, do not miss Jeff King's interview with current Git maintainer Junio Hamano.

Rate this Article