Will Git Drive Open Source Contribution

I know I’m not alone when I say that I’ve been hearing a lot more about Git lately. I have talked to others that have expressed interested in moving to Git and dropping use of Subversion. Now just to properly date this post… (SVN is currently on version 1.6.5 and Git is on version v1.6.4.4).

Gaining Traction

Just to show you some charts of how Git is gaining some ground and getting some awareness, here is the trend of Google’s searches for “git tutorial” (blue) vs “svn tutorial” (red):

Additionally, the trend for Google searches for “git vs svn” seems to be skyrocketing out of nowhere:

It would seem that there are a lot of others out there looking into the differences between Git and SVN. Is it because they don’t know what Git is? Maybe. Is it because they’re finding problems with SVN? Maybe. That’s why I’ve been looking into it.

The Pain of Subversion

I feel that Subversion is a big step up from using a version control system like Visual Source Safe. But I’ve also experienced my share of pain when dealing with multiple branches of a project. I’m always pleasantly surprised when a merge in SVN goes smoothly, but shouldn’t they always go smoothly? Why do I put up with the headaches while simultaneously expecting them each time? It’s time to remedy the pain and Git seems to address those pain points.

I still consider myself a newbie when it comes to Git, but what I’ve heard from others is that approving pull requests is much, much simpler than applying patches. Patch managers or project managers are allowed to “cherry pick” certain portions of commits, not the entire bulk of an individuals contribution. Many of the build errors on the CI server that I’ve committed are not adding files to Subversion beforing committing. I’ve gotten a lot better at this, but it still happens from time to time. When using Git, I’ve had great success by using “git status”, which shows me exactly what is unversioned. With this step as part of my workflow it’s been much easier to avoid adding files.

The Benefit of a DVCS

With services like Github, anybody can commit by pushing their code to their own fork and asking the project managers to pull their changes into the master. I likely don’t have to explain how the process works, you can figure it out own your own. The other benefits…

GIT kicks SVN’s butt wrt working copy. Same project pulled from the same SVN repo. GIT with full history 42 MB; SVN only trunk 134 MB. Wow!
- @JamesKovacs

Git has been designed to keep a smaller footprint. Since you have local repositories, it is faster; also, you don’t have to worry about doing exports since there is only a top-level “.git” folder in the main repository, instead of a hidden folder, in every folder and subfolder.

You can commit multiple times locally, then push these all to the master. This allows you to work offline and complete a feature, push it to your local master, then keep moving on to something else. When you get back to a connected environment, you can then push many commits to the master or have them pulled from your fork. “Working on a plane” is usually the common scenario that is mentioned when you’re listening or reading about committing locally.

Projects Moving to Git

The following projects use Git, are moving to, or have talked about moving to Git:

  • MvcContrib
  • Rails
  • NHibernate
  • Castle Project
  • RhinoTools (including Rhino Mocks)
  • rspec
  • Cucumber

Will OSS Thrive From Git

Anybody can predict the future, it’s the accuracy that always seems to be the problem. I don’t know that open source will thrive from projects switching to, or being on Git repos, but I am going to predict that it will help them. Only time will tell on how accurate I am with this prediction. Apparantly I’m not the only one that is inspired by this shift:

What I like about Git, makes me excited to develop….

I’m really anxious to hear some other opinions on Git. What do you think about Git helping out OSS projects? What do you think about Git in general?

About Chris Missal

Oh hey, I'm a Senior Consultant for Headspring in Austin, TX. I've been working in software professionally since 2006 and I really, really love it. I'm mostly in the Microsoft world, but enjoy building computer things of all sorts (to be vague). When I'm not slinging code, I'm probably out and about slinging discs, bowling balls, or good beer with great friends.
This entry was posted in git, Open Source. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I must admit at first I was skeptical that Git would be for me, I’m a Windows developer who almost never touches the command line. But using msysgit and/or Google’s Git Extensions it is the easiest version control system I’ve used, and definitely the fastest. I’ve still yet to see a really straightforward tutorial (most overcomplicate the issues).

  • Why do we, Windows developers, use something that can’t run natively on Windows? Mercurial seems so much more natural on our platform yet no one uses it in the .NET community. Mercurial is often not even mentioned by the people moving away from svn. I don’t get it.

  • Well I for one once thought exactly like Borek above, only that I was hooked on Bazaar instead of Mercurial. The thing is, I had to work on Git for a single project where I had no other choice, and after learning it everything just clicked for me. Yes, the terminology is not “intuitive” for people coming from cvs/svn/bzr/hg. After reading up on the commands a bit, though, it makes sense and it becomes a non issue.

    Where git really shines is when you are working on an open source project with active contributors. There’s no surprise there, it’s exactly what it was designed for. It makes it really easy for a developer to submit changes, and it makes it equally easy for the project lead to integrate those changes painlessly.

    And to comment on “Why do we, Windows developers, use something that can’t run natively on Windows?”. I never liked the idea of installing Cygwin just to get git going. With the creation of msysgit this is no longer necessary and both the command-line interface and GUI look like they are running natively. Give it a shot, it makes installation painless and easy.

  • Pingback: Develop in the Cloud - Tim Kellogg - How to Make an OSS Project Thrive()