I’ve been using Subversion for version control for the last couple of years. It’s a lot nicer than cvs and I was quite happy with it. Then last week Olivier pointed me towards a presentation by Linus Torvalds about Git. The talk got me interested in trying out Git and I started playing around with it.
Git was developed by Torvalds after the linux kernel developers were forced to stop using a closed source system and decided that none of the existing open source alternatives matched their requirements (see here for more info).
Next day I decided to move one of my svn repositories to git as an experiment to see if it improved my workflow. The answer: it did. A lot. When I moved from cvs to svn I felt it was a huge improvement and now moving from svn to git feels like an even bigger improvement.
So here’s a short summary of what I like about git, based on less than a week of using it.
Git is distributed - so I have a local copy of my repository on my machine. In practice what this means is that I don’t have to be online to commit changes to my repository. I have a copy of my repository on my laptop and a copy on my desktop and a copy on my server. I commit changes locally on the machine that I’m working on and I periodically push those changes to my server repository. No more giant commits when I don’t have internet access. This also has the benefit that local commits are much faster, so I tend to do them more often.
Creating and merging branches is ridiculously easy in Git. I never really used branches in svn because they were too much hassle. It was always just a single branch with tags created for major releases. Because Git makes it so easy to create and merge branches this has become part of my workflow. Now I create a new branch whenever I’m doing something experimental and then dump it if it doesn’t work out and merge it if it does.
Lots of little things that are difficult to elucidate. Here are a few examples.
Git supports both svn and cvs. You can import an entire svn or cvs repository into your git repository and export your changes back again. So you can use git locally on a project where everyone else is using svn. Git will translate your local commits to svn commits whenever you push back to the svn server.
Git feels fast. Part of this is because you’re doing lots of stuff locally instead of with a server. But it actually is really fast. Here’s a speed comparison with mercurial and bazaar. Git also has excellent compression. For example, importing the entire Rails svn repository into Git (over 7500 commits) gives a repository about the same size as a single export of one version from the repository. There are some other compression benchmarks here
So, in summary, I really like Git and in the short time that I’ve been using it I found that it has helped me be more efficient and improved my workflow. I’ve now moved all my svn repositories to git.
If this has piqued your interest have a look at the following resources.
thanks for referencing my google tech talk on git.
Thank you for this article, I will certainly be checking this out (even though I just blogged about SVN)!
hmmm, i always thought there was room for improvement with SVN. Still though, have one major problem with SVN etc and that is dealing with database application. if you make changes to mysql schema this is a fundamental change to your system ... now there all sorts of ways you can store it with svn like having a sql schema file in the directory structure but i think there is room for a more integrated setup.
I will defo check out GIT now. Looks very interesting.
Great post.
I knew about Git previously but never thought to give it a try since SVN appeared to be suiting my needs just fine but you made some great arguments for git so I definitely be testing it out soon.
Post new comment