Git at 15: How Git Changed the Way We Code

Fifteen years ago a number of the Linux kernel developers tossed their hands in the air and gave up on their version control system, BitKeeper. Why? The man who held the copyright for BitKeeper, Larry McVoy, withdrew free use of his product on claims that one of the kernel devs had reverse engineered one of the BitKeeper protocols.

Linux creator Linus Torvalds sought out a replacement to house the Linux kernel code. After careful consideration, Torvalds realized none of the available options were efficient enough to meet his needs:

• That a system does the opposite of what Concurrent Versions Systems does.
• It would support a distributed workflow (similar to that of BitKeeper).
• It must offer safeguards against corruption.
• The project must scale to meet the intense demand of Linux kernel development.
• Patching should take no more than three seconds.

Given Torvalds’ prowess as a developer, he quickly realized his only choice was to create the tool himself. And so, on April 7, 2005, Mr. Torvalds launched his new project, git. According to Torvalds, the project was named after himself.

Issue the command man git and you’ll see the official name of git includes the slightest bit of humor (Figure 1).

Figure 1: The stupid content tracker.

Since its original release, git has become an incredibly efficient and easy to use tool. Git is also one of the most widely used source code management systems on the planet. According to the 2018 Stack Overflow Annual Developer Survey (the last year they included a Version Control question), 87.2% of developers used git.

Just What Is git?

For those select few developers who have never experienced git (or those who aren’t developers, but are curious), git is an open source Versioning Control System (VCS). A VCS is a tool/system/service used for the management of changes to documents, computer programs, websites, and just about any collection of information. With regards to software development, a VCS helps a team of developers manage changes to source code over time.

“Don’t worry, we’ve all been there. We’ve all made mistakes. Git makes it easy to undo every mistake you can make and then some.”– Mario Danic

But git approaches the task a bit differently than most Version Control Systems. Most systems store information as a list of file-based changes, so both the file and the changes made to the file over time is stored. Git, on the other hand, looks at data as a series of snapshots on a miniature filesystem. Any time a developer commits or saves a project, git takes a snapshot of those files and stores a reference to the snapshot. Git takes this one step further, runs a diff on the files, and doesn’t store any file that hasn’t changed, but links back to the previously stored (identical) file.

This method of storing snapshots makes git incredibly efficient.

Git also works both locally and remotely. Developers install git on their computer and then can pull projects, work with them locally, and push their changes back. The basic git workflow goes like this:

1. Create a repository (a project) with a git hosting tool (such as GitLab).
2. Clone the repository to your local machine.
3. Add a file to your local repository.
4. Commit the changes.
5. Push the changes back to the remotely hosted project.

Source: Eclipse Community Surveys.

Changing How We Code

But how has Git changed the landscape of development? Ask just about any developer around the globe and the conclusion you will draw is “profoundly.”

In fact, Sean Callen, Director of Web Engineering at System76, said, “It’s hard to quantify just how much better git is coming from SVN and IBM Rational ClearCase.” Callen qualifies that, however, by adding, “Previous tooling felt clunky and collaboration was never as fluid as it was with git. Toss GitHub into the mix and you’ve got an experience that’s unrivaled by the others.” More importantly, however, Callen believes that git has certainly made his work easier.

But what kinds of changes has git made since those early days? “I have somewhat of an obsession with a clean git history,” Callen said, elaborating that “improvements to git-rebase and git-cherry-pick have made it possible to work collaboratively with others while maintainable a usable history.” The git-rebase and git-cherry-pick tools have come to Sean’s rescue not only for his own work, but when helping other team members.

“When Git appeared, as a novelty, it was interesting to see the ‘different way’ it presented things,” said Mario Danic, lead developer/senior software engineer for Nextcloud. “And while the ideas behind Git remain unchanged, the overall experience (for me) has changed significantly due to improvements to the facade which make it not only simpler to use even in complex situations but also lowers the barrier to entry and education needed for the more junior developers.”

And speaking of tools, Callan proclaims the command line interface (CLI) is the way to go. “I’ve tried some GUIs but I found time and time again that I came back to CLI to get things done. One of git’s strong suits may very well be its approachable CLI.” From within that CLI, git has, over the years, built a “plethora of tools that enhance the CLI experience further, like GitHub’s own recently released CLI tool,” Callen claimed.

What Does the Future Hold?

It’s anyone’s guess what the future holds for git. Now that the git volunteer development released its own CLI tool, the sky’s the limit for what programmers and teams of programmers can do with the software. But what would programmers want from future git releases? If Callan had his way, he’d be happy if git did nothing. “I’m happy with git and how well it has performed for me over the years. From enterprises to small start-ups, popular open source or personal project, I can’t recall a time I felt git was lacking.”

“One of the bigger shortcomings that git had in its beginnings was lack of documentation. I think that’s being rectified more and more,” Danic said. As to its most glaring shortcoming, Danic warns, “While it’s most definitely widely spread out and adopted by the developers, junior people just coming in still have the notion that git is somehow ‘hard’ because that’s how it was in the beginning. I guess this will quickly fade out as people realize that is not the case and as they learn more about it, but it will take time.”

Danic advised new users, “Don’t worry, we’ve all been there. We’ve all made mistakes. Git makes it easy to undo every mistake you can make and then some.”

Git is 15 Years Old: What Now?