Happy birthday, Git! Our expert check for Git’s 15th birthday
The version control system Git has become the de facto standard when it comes to decentralized management of source code. Hardly any other system has had such a strong influence on the way we develop software today over the past decades. For the occasion of Git’s 15th birthday, we spoke to seven experts about their experiences and wishes for the future. In our Git expert check, they also talk about what is still missing in Git and what features they like best.
JAXenter: Hi and thank you for taking part in our birthday special. Git is celebrating its 15th birthday, so first of all the question: How has Git revolutionized the world of software development in the past 15 years?
Jodok Batlogg: The way team-oriented software development works has been revolutionized over this time. The whole concept of agile working, be it with Scrum, Kanban or other methods, would be unthinkable without the functionalities of Git—Git has made agile, distributed, team-oriented working possible. There’s a reason why developers who move from one company to another can be productive immediately. Take the “Git Feature Branch Workflow,” for example, and everyone knows what you’ re talking about. Sure, there have been tools like diff before, but they were used more for patching files. Nowadays, life without “pull requests” would be unthinkable.
Tobias Günther: Software development has become much more collaborative—and therefore more professional. A few years ago, version control was still an “optional” step in many development teams. Today, version control (which is now almost synonymous with “Git”) is part of every developer’s daily toolset. And even more: Git has also become the basis for many other services (such as continuous integration). So, version control with Git has become a “platform.”
Marco Schulz: Hi Dominik, of course. Well, source control management systems have been around for quite a while. Some of you may know CVS and its cumbersome nature from legacy projects. Compared to that, its successor, Subversion, was like a race car, and it was similar when Git entered the stage.
Software development has become much more collaborative—and therefore more professional.
Jordi Mon Companys: Git has provided a solid, free and open source source code management for everyone. Any developer, regardless of their experience, can download a lightweight binary, learn a few commands or use GitLab and kickstart their software project in minutes without Git getting in their way. Quite the contrary, using Git guarantees the complete history of their project will be stored and the capabilities to collaborate with anyone in the world are a natural part of the project itself. Git has made collaboration and gradual software development available to everyone and the world has taken it by storm.
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.
Daniel Stender: For various reasons, Git has simply established itself as the standard platform for open source.
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. 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. That also gives developers a great deal of flexibility; because the tools and data are local, developers can create their own individual workflows independent of each other.
Git also moved the software development industry to be better communicators. Version control systems have always allowed developers to describe their changes, but without good tools for examining the history later, many people didn’t see the value in it. Git has fast and flexible tools for finding the commits which introduced particular code or even a particular observed behavior.
Git is eating the world – with GitHub and GitLab
JAXenter: Because of the popularity of GitHub and GitLab, Git has effectively won the battle for supremacy in version control. Why is there nothing comparable with Mercurial or Subversion, or why nothing as successful?
Jodok Batlogg: I remember the days when I worked with CVS, one of the first version control systems for software. I also remember the brief switch to SVN, which for the first time was also able to work with WebDAV via the HTTP(S) protocol. However, the friendship was short-lived, my first commit to GitHub was in September 2009.
Why did Git prevail? If I limit myself to two reasons, one is the fact that the tool could just do anything. Linux kernel development is one of the most complex software projects ever, and has helped shape the functionality of Git from the beginning. This ensured that the functionality was rock-solid. On the other hand, the
git command line tool strikes the right balance between power users who do everything from
cherry-picking, and beginners who get by with
push. Ok, a third reason: platforms like GitLab or GitHub have made it super consumable. With a web interface, as SaaS—and yet with full power under the hood.
Tobias Günther: A new technology (which Git was just a few years ago) always hinges on its ecosystem and the community that develops it. And GitHub was a stroke of luck for Git, because it had its fingers on the pulse of time. Another reason is, of course, the concepts that Git pursues: decentralization has many advantages (e.g. over Subversion), as well as the excellent implementation of branching, staging area, stashing, etc., compared to other decentralized systems like Mercurial.
Git is simply more technically advanced than Subversion.
Marco Schulz: Leaving aside the big name that is so closely associated with Git, there are many points that were consistently done right when designing the tool. A lot of the experience that Linus Torwalds gained through his work on Linux was incorporated into the design. If you compare a revision in SVN with Git, you’ll find that the commit identifier in Git is a UUID, and Subversion uses only a simple auto increment. These independent UUIDs bring the tremendous flexibility we value in branching and merging. Another example is the overly academic solution that IBM Synergy once used, which was intended to provide stable builds. With pull requests, Git has been able to establish a much lighter process here.
Jordi Mon Companys: For the case of Subversion, there are several reasons. SVN is a centralized VCS so the distributed, asynch part of Git is not available for its users. That is a huge appeal to Git. Also, GitLab builds a complete DevOps platform on top of Git, so effectively it’s broadening the scope of Git to provide users with a tool for all their software development and deployment needs, something SVN is incapable of doing.
Daniel Stender: Git is simply more technically advanced than Subversion. It doesn’t matter that SVN is much easier to use. Mercurial and Bazaar offer similar concepts to some extent, but may not be as good in terms of the overall package. External factors, though, also play an important role in the question of its success.
Jeff King: 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.
„Git is close to perfection“
JAXenter: What features are currently missing in Git?
Jodok Batlogg: Honestly, I can’t really think of anything here!
Tobias Günther: I don’t think Git needs any more features: after all, it is and will always be a version control system! The task of making all the power of Git available to developers is more of an ecosystem task—for platforms like GitHub or tools like Tower.
Marco Schulz: I am definitely bothered by the complicated mechanism you have to set in motion to get your typos out of a commit message. This was much more convenient in SVN with a small hook script.
It is the simplicity and reliability of Git that make it so universally loved.
Jordi Mon Companys: I would argue Git is pretty close to complete maturity. Of course, there are all sorts of improvements in performance and usability that could potentially be implemented but there are few things missing in Git. Ideally, making Git super flexible and being able to work in a client-server (centralized) mode would potentially broaden its reach to certain industries but given Git’s contributor communities discussions, it’s highly improbable that will ever happen.
Brendan O’Leary: I think that there is very little missing from Git. It is the simplicity and reliability of Git that make it so universally loved. However, I do think that managing multiple projects with shared dependencies presents a number of challenges. The usability of Git submodules could be greatly improved, and a focus on dependency management could bring interesting changes to Git itself.
Daniel Stender: Built-in artificial intelligence for the automatic resolution of merge conflicts.
Jeff King: Repositories are only continuing to get bigger and bigger, so the focus for Git in the near future is determining how it can continue to scale with these repositories and enable developers continued access to them.
Experts and their favorite functions
JAXenter: What is your favorite feature/command in Git?
Jodok Batlogg: Over the years, I have degraded from developer to CTO. So, my standard flow is all I use. And, fortunately, my longtime employee and friend Christian (“chaudum”) captured that a long time ago (2015).
Tobias Günther: What I love about Git is that you can undo almost every mistake you make. The set of “undo features” is really huge and helps developers sleep better at night 😉
Marco Schulz: For my daily work, I often need the possibility to write the history object with own selections in text files. This helps a lot to get an overview when working on new projects.
Jordi Mon Companys:
Brendan O’Leary: It’s not the fanciest feature, but
git reset has incredible power.
git reset provides what I call a “magical time machine” allowing you to always understand what happened previously, and save previous work if you make a mistake.
$ git checkout -b mybranch
Jeff 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 log -S are all indispensable parts of my toolbox.
Can it get any better?
JAXenter: A glimpse into the future—what comes after Git?
Jodok Batlogg: The whole thing in real time, I believe. Or, in other words, all branches are synchronous everywhere. That would be cool. Or “micro merges” that happen constantly. Including deployment to production!
Tobias Günther: I’d like to have this kind of crystal ball, too 😉 Maybe it’s not at all about what comes after Git, but rather about what is created alongside Git. In the last few years, so many exciting apps, tools and services have been created on the basis of Git that I would rather believe in this!
Git solves the version control problem more or less perfectly.
Marco Schulz: Even though SCM tools such as Git are essential for developers today and are part of every job advertisement, many universities do not place any importance on teaching students the power of such tools. There is still a lot of catching up to do here. I also think a future evolution of SCM systems could be the handling of office files. We’ll see if anyone will pick up on this topic.
Jordi Mon Companys: Nothing. Git for everything.
Brendan O’Leary: The final frontier for Git really is large file and asset management. In the age of ultra-realistic video games, AR and VR developers have an increasing need to manage large numbers of large scale files. Traditional Git doesn’t solve for those types of use cases well, and add-on tools such as Git LFS have had a hard time with other Git concepts. The new Git native features with shallow clones and partial clones have helped answer this.
Daniel Stender: Git solves the version control problem more or less perfectly. What comes after version control?
Jeff King: Git brought decentralized source control to the world, but software development is much more than just the source code. I’d love to see more decentralized tools for developer discussions, issue tracking, and all the other tasks software developers face.