Wednesday, July 21, 2010

First taste of Git

I am using Subversion for most of my development. But recently I started to have a look at Git, a very popular version control tool at the moment. One of the reason I look at that is because the tool is created by Linux's father, Linus Torvalds. Another reason is because I would like to know why the popularity is growing so quickly. Is it because of the reputable creator? or the usage of Git is far better than Subversion?

After using it for a few days, there are few things in Git I found are doing really good.
** I am running both Git and Subversion using single machine (which actually took out the benefit of offline mode for Git). And I am using command mode for both tools.

First, it's so much faster (even took out benefit of the offline mode from Git). So far I'm using only a few command, like pull, push, commit, stash, checkout, etc... The way that Git process is just so fast. It's fast that I couldn't believe in the first use. Initially, I thought I didn't use the commit command properly. Because the commit command happen and finish right after you just click enter. Although comparing to Subversion, it does not give you lots of information of the commit, maybe that's the reason why it is faster? by doing less I/O? or maybe the algorithm of doing diff is much better? I don't know.

Second, it is really convenient to use stash. One thing I do a lot in Subversion is to checkout some branches, make a few changes and commit them back. It all depends on the urgency of what are you working on. Sometimes you've done half way through on a user story, but suddenly you have to do something else on different branch. It's convenient to stash your current changes, pull other people's work and then unstash your own work.

Third, the idea of pulling from other people's work is great (Every clone has their own master repository). I basically clone several copy of the project to different location. I commit a new file for 'A copy' in its master repository. Then I can pull that new file from 'B copy' (merge to B's master repository). Eventually, when 'B copy' push back to the bare (parent) repository, 'A copy' will get the same status as 'B copy'. So basically I don't always need pull from bare repository. I can pull whoever's works I want. One scenario I could think of doing this on a single user project is I can clone 2 copies from the bare(why? because I always had different idea in different time). I can have one source copy for my desktop, one copy for my laptop. I can work at my Desktop at night, and work on a laptop in the morning.  The code progress for those 2 machines doesn't have to be in the same pace. So instead of always committing stuff back to bare repository (and then update to the other machine), I can fetch to see what other copy up to and then pull whatever I want to pull. If I confirm those idea is worthwhile to create, I will then commit back to the bare repository.

There are so many good things about Git. I personally quite like it. I think I will dump Subversion and keep on using this for my own projects. If you want to know more, there are so many article, blog to compare between Git and Subversion. Just search from Mr. Google. If you got some other good scenario which you think using Git is better than Subversion, or maybe the other way round (which I doubt it), feel free to comment it here.

1 comment:

  1. rebasing is also really cool. i find it really useful being able to commit as much as i like and then being able to recombine/reorder the commits later before pushing.

    ReplyDelete