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 v188.8.131.52).
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!
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:
- Castle Project
- RhinoTools (including Rhino Mocks)
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?