Moving from Subversion to Git for revision control

Posted on

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.

Distributed/Offline

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.

Easy branching

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.

Little things

Lots of little things that are difficult to elucidate. Here are a few examples.

  • Moving a file. You just move it. You don’t need to tell git to move it or that you’ve moved it.
  • Moving between branches. You don’t even have to change directory - just type git checkout branchname and git will change all the files in the working directory to those from the current branch.
  • The command names and options seem to make more sense and it’s been easier to learn all the git commands and guess how to do things.
  • The entire repository is stored in a single .git directory. This keeps your directory clean. Svn scatters files all over your directory tree.

SVN support

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.

Efficiency

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.

Some resources

If this has piqued your interest have a look at the following resources.