5 Reasons Why Git Beats Svn (or why you gotta git that git)

With the arrival of the new Distributed Version Control Systems (DVCS) such as git and mercurial many are asking….what’s the point? Do I really need to switch to a new source control system again? I *just* learned subversion and now it’s all changing again!!!

Other people, like the famed Joel Spolsky, are more blunt:

Here’s the part where you’re just going to have to take my word for it.

Mercurial is better than Subversion.

It is a better way of working on source code with a team. It is a better way of working on source code by yourself.

It is just better.

Now, instead of just saying that Mercurial or Git are just better, I’m going to give you five good reasons why – in easy, scannable, lovable, blog format. So without further ado, let’s start with #1:

1) Offline Commits

Have you ever got your code to a point where you wanted to check it in, but didn’t want to break the build for everyone else? Maybe you’d just spent 10 hours refactoring and felt like you’d really made some progress, but didn’t quite want to publish your creation to the world. But it still would be nice to take a snapshot of it in source control.

What about when you’re on the road and want to do a little coding, only to realize you have no connectivity to your central svn server to do your commits.

Git solves both of these problems by using a local repository. That’s right you get your very own repository right on your machine. You make your commits to it, and only push to the master repo when ready.

2) Speed

Because most operations in git work off the local repository they are lightning fast.

Instead of connecting up to the server repository to see the history on a file, you just look on your own hard drive. These operations are an order of magnitude faster because there is no network latency to deal with.

Not to mention that git was written by Linus Torvaldus – the guy knows a thing or two about optimizing code.

3) Push to Multiple Repositories

Once you have local repository how you like it, you can then push it to as many other repositories as you want. This concept is brilliantly illustrated by Heroku – the rails in the cloud site.

To deploy to heroku (after some simple set-up), you simply call:

git push heroku master

And your code is automagically deployed to the cloud. Want to push the same code to a web source control site like github?

Fine (after some simple set-up), just call:

git push github master

Now you’ve pushed the same code to two repositories.

4) Stops .svn File Pollution

Have you ever copied a code folder to a server only to see many, many more folders and files going across then you expected? After a quick slap to the head you realized that all of the hidden .svn folders and files are getting copied across as well.

That’s right. You forgot to do an svn export to clean out the folders before copying them – Doh!

With git, you don’t have to worry about about all of your folders getting cluttered with hidden junk because it only adds a folder to your top-level directory in your source tree. The rest stay beautifully clean!

5) Branching is Fun Again

Raise your hand if you’ve ever created a branch in subversion, worked on it for months and then suffered mightily when you tried to merge it back in. I’d be amazed if you’d used subversion for any length of time and not encountered this problem.

Git elegantly solves this issue by focusing on changesets rather than revisions. You see while subversion tracks revision (or what the entire tree looks like at a given point in time), git is much smarter and instead tracks changesets which are all the little changes that each person has made.

So when it comes time to do a merge, git has a lot more information and can tell that the function was just moved, not that it’s a conflict.

Conclusion

So why hasn’t git taken over the world yet? Well, the biggest problem, in my not so humble opinion, is lack of a slick GUI windows client. Many windows developers, for better or worse, are used to working with a nice GUI for source control and going back to the command line just isn’t a viable option.

Once a suitable windows client exists, be prepared to hear a lot more about git. I predict it will infect the windows world in the same way it has the ruby and linux world. Just as we all jumped from VSS to svn, soon we’ll be jumping to git.