A few days ago, our code repository server froze. Nothing a restart couldn’t solve, but this was the fourth time this month. The computer has been running continuously for a couple years, with a few developers constantly committing and pulling changes, uploading files, etc., and it had apparently had enough. Seeing this as an opportunity to fix up our development process a bit, I wiped the drives, and re-installed the OS.
The first thing I wanted to change was our code versioning system. Our office has been using Subversion (SVN) as our code repository for a couple years now. It’s done the job well, and has saved our butts on more than one occasion, but there were a few things I didn’t like. As I’ve mentioned in previous posts, I like moving around when I work; hitting a coffee shop in the morning, or taking my laptop to the local bookstore on a hot day. Subversion forced me to always have an internet connection to commit changes or make new branches. As a result, I would perform larger commits, or have branches pulling double duty, which is far from ideal. Further, setting up and maintaining the permissions with ssh and multiple developers is quite a pain on Subversion.
A few of our developers have used Git for some open-source projects, and we all quite liked it. We’ve been talking about changing for months, but we couldn’t justify the effort until we had to re-install everything anyways. We decided to use Gitosis to manage the Git server, setup the permissions, and manage users (good tutorial here). This proved to be fairly simple. I then imported all of our previous projects with git-svn with some help from this post. Next, our system was configured to send out a summary e-mail every time a developer pushed a change. Finally, I modified our deploy files so the servers read the code from our new Git server rather than our old SVN server. The entire process was completed in under two days.
While many of us had used Git before there was still a learning curve. I found a very useful guide called “Git Magic”. It starts off with the basics that all developers should know, but moves all the way to “Git grandmastery” in chapter 7.
Final thoughts:
Git has more of a learning curve than I expected, and is more complicated than Subversion — but it is so much more flexible, that I think it’s worth it. You can really use it however is best for you. For some developers, it won’t be much different than working with svn, but I’m really appreciating the differences. I read an interesting analogy comparing clones, branches, tags, etc. with multiple desktops, windows and tabs. The more options available, the longer it will take for a person to come up with the best system for them, but once they figure it out, they can really fly.
I would love to hear your thoughts on Subversion vs. Git (or any other systems you recommend for that matter). Why do you think one is better than the other?
