Monday, June 02, 2008 2:59 PM
I've recently spent some time playing with Git as a source control system. Initially, I'd ignored the Git hype since I've always been more than happy with Subversion, however, a recent Hanelminutes episode mentioned an interesting idea. The episode featured a Rails shop in Portland which was in the process of migrating from Subversion to Git. The team mentioned that while they were still using Subversion as their back end source control, they had taken to using Git for client side source control. This allowed them to make finer grained, smaller commits from their desktop throughout the normal course of development.
Imagine making a tiny commit a normal part of your development workflow. You write a test, you make it pass, you check that all tests pass, then you check in the code. Imagine being able revert back to the state of the codebase after any test was added. Granted this is completely possible with Subversion as well, but since Git is local, the idea is that your commits will be very quick and not get in your way.
That's the elevator pitch, and you have to admit, it's a pretty good one. I've been using Git as my client side source control system on two projects over the past two weeks for two separate projects, each of which are maintained in a different offsite Subversion repository. Here are some observations thus far...
- I love the idea of making small incremental commits as I work and then only making a true commit after a significant amount of work as been done. For example, I can commit to Git after every test, but only commit to Subversion after a feature is complete.
- In realty, however, the commit to Git seems to take a bit too long to make this as zero friction as I would like. In fact, my local Git commits seem to take even longer than my remote Subversion commits. I'm not sure why this is unless it has to do with the compression that Git is using to keep the local repository so small.
- I typically use Subversion from the command line anymore simply to save taking my hands off of my keyboard. However, I still have TortoiseSVN installed and apparently I'm a little more dependent on it then I had realized. Even though I work mainly from the command line, I still rely heavily on TortoiseSVN to tell me at a glance what the status of my codebase is on disk.
- I've really been missing this with Git. I can use the git-status command but I have to take the explicit action to do that, whereas the information is automatically shown to me with TortoiseSVN. The same goes for exclusions of certain file types and folders. I can do it from the command line, but its not as easy as it would be from a shell extension. For the record, there is a project called GitCheetah which aims to bring the same sort of shell integration to Git that we've enjoyed in Subversion. However, it's still in its early stages and it's still a little raw.
Those are probably my two biggest beefs so far. You may get the impression that I don't like Git but that's actually not the case. I've really been digging having a completely local repository there at my fingertips. Also, I need to be fair: the two issues I mentioned with Git are two areas that Git isn't really designed to handle. Git is designed to excel at branching and allow for you to work completely disconnected yet still retain a complete repository history on your machine. Git also isn't designed to act as a client side front-end for Subversion (they mean to compete directly with it) though I've been using it as such. I haven't had experience with the branching yet but I have to admit that having the ability to work completely disconnected is pretty nice. I'm typically online 90% of the time, but in the rare occasions I'm not its great to still be able to work and commit at my normal pace. In the past, when I worked offline I would typically have to hold back my commits to source control or combine several increments into one commit when I finally got online if I was disconnected for a significant amount of time. I hated lumping everything into one commit, but with Git I can commit as many times as I like to my local repository and then simply push all of the commits back up to Subversion when I get back online.
Although I'm still undecided if Git will become a standard part of my toolkit, I'm definitely intrigued by the possibilities. I would recommend that anyone who may be looking for a new way to include finer grained commits into their workflow to give it a try.