How Git redefined open source software development

Register or Login to like
Register or Login to like
words saying developing possibilities

It's not hard to come up with a dozen different reasons why the rise of open source development has been a watershed event in both the software and hardware industries. All of us can build new web applications faster with our feet firmly planted on the shoulders of jQuery, Bootstrap, and Apache. Languages like Ruby, PHP, and Python power the Internet, and operating systems like Linux and FreeBSD provide the foundation for thousands of companies and services.

But open source isn't just about the free tools we have access to, it's also about the community of developers that will help support crazy new ideas and give them a chance to thrive, grow, and change the world; ideas that would never see the light of day in a closed source world.

My favorite example of this is a tool near and dear to my heart because it made my little niche of the development world exciting again: Git. Before Git, the version control world had grown stale; the tumultuous 90s had given way to a Cold War between versioning superpowers in the noughties. Git brought back debates about version control workflows! Heck, just having people care about version control tools again was fun. For versioning nerds, it's been nirvana.

Git is a brilliant piece of software that has redefined how we do open source development, and software development in general. Certainly there were other distributed version control tools before it, but nothing in my time in the industry has so dramatically changed how we version and share our work.

It's a bit insane though. A huge amount of its power and flexibility is provided by a core versioned file system that can be used in any number of different ways. Built on top of that core engine are dozens of commands with dozens of flags that all manipulate that system in useful, if occasionally unpredictable ways. Many of those commands have evolved separately, written by different developers. As such, they can take very different approaches to similar problems.

Git was also written by a community that is very comfortable with a command line. They are accustomed to working in a guardrails-free environment: anyone who has accidentally run 'rm -rf *' in the wrong place will tell you it's a mistake you only make once. A side effect of that is Git doesn't have nearly as many guardrails as a user might expect from a version control system.

A personal favorite example of this is the reflog. If you're not familiar with Git, it can be roughly described as a local log of the version control operations that have changed your versioned files. The reflog is your savior when you run the wrong command and by all appearances lose all your work. The great thing about Git is it's never gone, you just need to know where to look.

Now imagine a world in which Git was created in a stereotypical closed source company. Imagine the board meeting where it is revealed:

Board: "That is an amazing piece of technology! This is going to change everything. Are there any challenges you see?"

Dev: "Well, we do find that occasionally we accidentally delete our current branch and lose all our work..."

Board: "Well, certainly that's just a bug? I imagine you'll just add a guardrail to prevent that data loss?"

Dev: "It's not really a bug. We just need to learn how to use the tool better. We have a solution to mitigate accidental data loss though."

Board: "Thank goodness! What is it?"

Dev: "We've gone with a more general purpose solution. We've put in a separate versioning system called the reflog so we can version your version control operations. If you delete your branch you can just scan the reflog for the appropriate SHA and recover it!"

The board slowly backs out of the room.

As posts like Steve Losh's Git Koans show, there is much zaniness to Git. I personally have a hard time imagining a company building and selling Git as it is designed today. There are too many inconsistencies and too many traps for new users. But those inconsistencies and traps are a natural side effect of being a powerful and flexible tool. Git without those rough edges isn't necessarily the Git we all know and love.

The good news is the open source development community was there to nurture and support it, adding awesome features like bisect and providing volumes of great documentation and tutorials to teach newbies the ropes. That support helped make a diamond in the rough very nearly the most popular version control system in the world.

We all have that crazy idea that we've pondered but aren't quite sure what to do with. It can be scary to try to bring those ideas to life—failure sucks. Spending your weekend building something that no one else ends up looking at can be disheartening. The good news is if your idea has some potential to it, there is a community out there that will want to help you make your crazy diamond shine. Who knows, that weekend project you've had kicking around in the back of your head might revolutionize software development, too.


A jack of all trades and master of some, Matt Attaway has worked as a tester, developer, researcher, designer, manager, devops engineer and elephant trainer. He currently manages the open source development group at Perforce Software, but prior to that he lead a test team working on the highest profile projects at Perforce.


Git is a great tool, and I use it often.

But its "inconsistencies", "traps", and "rough edges" are not a requirement at all. They are bugs, pure and simple. "It works as designed, it can't be a bug" is simply not a valid argument for UI problems. First step: Admit there is a problem.

The good news is that many of these are relatively easy to fix. First identify the key problems; the page is not a bad start. Then figure out improved syntax to support in *addition* to the old syntax, and modify the documentation to encourage using the new syntax.

I'd agree that the syntax inconsistencies can and should be fixed, but it feels to me the lack of guardrails, the reliance on the reflog, and the impermanence of history that Losh talks about in his Git Koans are unlikely to change. They also strike me as part of the reason Git is considered to be very powerful and flexible; there's very little it will stop you from doing.

I'd really like to spend some more quality time with Mercurial; the bit that I've spent so far has lead me to believe it has almost all of the power but with a much more consistent interface.

I think it's more accurate to say that distributed version control systems have changed the way we develop. not git. Too often people attribute the benefits of DVCS sole to git, and use that as a reason to hold it above centralized ones.

Lots of projects still use SVN, and they get by just fine. And Bazaar and Mercurial are both superior to Git. These are examples of distributed version control that doesn't have to be so hard to use. The best tools just get out of your way.

That is definitely more accurate; Git just happens to be the system most people know about. With the popularity of GitHub and Git's usage in the Android and iOS dev worlds it's easy for DVCS to get conflated with Git, but there are other great open source tools that shouldn't be forgotten.

Being written by Linus gave Git a platform that other tools would be hard pressed to match. If he had written Hg I suspect we'd all be talk about Hg and MercHub.

That said I'm very excited about some of the work that Hg is doing; the ability to safely rewrite published history that they are talking about could be game changing and really push what we all expect out of our version control systems. Hooray for competition!

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.