Thursday, May 29, 2008

GIT

A couple of reasons have led me to play around with GIT. I have had experience with CVS and Subversion. I use CVS at work, and use Subversion for my personal projects. Both have their pros and cons, and I heard a tons of good things about GIT. Linus wrote it and uses it for the kernel development - that's good enough!

After a ton of reading up on it, and watching
Randal Schwartz's presentation on git, I was inspired to get git and use it. It hit the spot - I have always had a few issues with the source code management systems out there and git supposedly has thought of everything -
  • So here's a typical scenario - I checkout the source code from the HEAD at my work repository. I want to refactor it but don't want to break anything. I just want to change a few things, make them more efficient ( yea right! ) and basically try out a coupla things I couldn't try out earlier due to deadlines. So I edit code, play around with some kewl new technology, refactor it. By the end of the day, my editing has been finished. But its not perfect and frankly I rather not commit these changes since I really don't wanna break the code and/or I don't want the rest of the world to know I made these changes! So the only option left for me is to delete these changes ( or make a local backup copy ). I will have to start working on the main branch again, I guess I'll have to forget about this entire day's of work. The problem with that is that I have lost my work; however trivial it was. Hence the concept of a distributed version control system appeals to me. I clone the repo and play around all that I want. Ooo the concept of private branches...

  • Another interesting feature of distributed development is that since you "clone" the repo to your hard disk, you always end up having the entire repo, the history of each and every file - all readily available. You can work on it offline, and commit it only when you are absolutely ready. This also helps when more than 1 person is working on the same piece of code, and needs to be able to make changes all the time.


  • Every time I have to work on >1 different branches of the same project, it is always a hassle. I don't know of all the .cvs ignore files that are lingering around, and I always make mistakes committing my changes. I tried out git and tried out checking out 2 different branches. I tried out editing them, and then checking those changes in. Wow, that was simple! It really is very intuitive and the non-polluting of any sub-directories makes it so easy to learn and use git.
Git also delivers on a few other things - these weren't amongst my initial requirements, but are very useful now.
  • For legacy humans ( ;) ), git has a "backwards-compatibility" feature to work with cvs clients. The end user does not need to learn 5 extra git commands, and can use cvs-style commits/checkout/branch to basically use git. I guess in my company, if I was trying to push Git, this would be an awesome plus-point!

  • Git has funky merge and rebase features for tons of different users working on the same code. Merging is always a nightmare, and its not too bad with git. Of course you are going to break something somewhere, but thats what a developer in a team has to go through!

  • It has to be real fast - the linux kernel has 25000 files
After using git for a few days now, I feel like I need to use it in one of my personal projects. I have been looking forward to working on something exciting.

Think Globally, Work Locally.....