Switching to Git from CVS and Subversion March 4, 2008

I’ve been using CVS for at least 6 years now. I switched to using Subversion maybe in the past 3 years. When I switched to Subversion from CVS, I really didn’t understand what the fuss was about. The feature-set was really quite similar and it seemed basically like a matter of personal (or political) preference. People insisted that “Subversion was better” and if you weren’t using it, it’s because you were an ignorant jerk. So I gave into the peer pressure and started using Subversion whenever possible. Admittedly, I found a few things that Subversion would do that CVS just wouldn’t. Symbolic links, for example, are one thing that Subversion can handle and track while CVS simply cannot. However, the general structure/organization for your project between the two systems of version control are pretty much identical. That is, there’s a centralized repository that every developer uses for checking out and committing code. Furthermore, any action requires some communication with the server. Branching and merging has been equally difficult in both, in my experience, so as a general rule I stay away from doing either and keep all code in the trunk of the project’s repository.

Git went an entirely different way. Each developer is essentially working with their own repository. Changes are committed locally without any need to send files to a centralized repository off in cyberspace. This means that even sans internet, you can travel and code without having to change a thing. I won’t go into too much detail here. For that, you should watch Linus Torvalds tell you why Git is the best tool for the job.

Unlike my switch to Subversion from CVS, version control with git is drastically different from anything I’ve used in the past. This made the switch a little uncomfortable, but luckily there are guides written specifically for people like me who have not seen the light until now: (See git for CVS users). While such guides are helpful for getting started, I’m committed to learn how git is supposed to be used, not how to retrofit git into my CVS-tainted mind.

Things I love about git so far (in no particular order)

• “git commit” will not commit every changed file by default. I LOVE this difference between git and CVS/Subversion. Instead you must use “git add <filename>” (even if the file is already tracked by git) to indicate that you would like the file to be included in the next commit. This allows you to be working on several files at once, but only commit the ones that are “ready” to be committed.
• Branching/Merging is supposedly infinitely easier with git, but I have yet to try this out. I’m looking forward to it though!
• Because git is not centralized, you can “pull” from any repository you like. So say developer A has added some functionality that you, as the project maintainer, wish to incorporate into the main branch. You would run “git pull <from developer A>” to get their changes into your workspace, and go from there. With CVS or Subversion, you would need to give developer A write-access to your repository, which, unless you have the utmost trust for that person, you may very well not want to do. With git, anybody can easily make contributions without the project maintainer having to dole out access or lose sleep over security. I’m sure this is one of the things that makes git the perfect version control system for huge projects (such as the Linux kernel).

I’ve only been using git for a couple weeks now, so I’m still very much in the learning stage. Every day that I use git, I end up learning how to do something that I could never have done with CVS or Subversion. Its power, flexibility, and ease of use make it the best tool for the job for this developer. If you haven’t tried it yet, you owe it to yourself to give it a test drive. After all, it’s free.