Working with Mozilla's Mercurial l10n repositories, I have gently been forced into learning about this type of distributed VCSs, and what a revelation it turned out to be!
Having only used Subversion (and a negligible bit of CVS) before, the ideas and principles of a decentralized VCS seemed chaotic and too cumbersome, to say the least. After reading (most of) the Mercurial Tutorial, however, my fear and reluctance turned to intrigue.
Why a DVCS?
For me it was the ability to do local commits that really caught my interest. Although local commits have been linked to so-called "cave coding", I still believe that it has more pro's than cons.
For someone reasonably serious about the quality of the code he commits, it is very irritating to have to commit changes that I'm not yet comfortable with. For example, I start refactoring some key component while I'm not sure if I will be able to complete it in time for the next release (or some arbitrary deadline). In stead of having to commit such serious changes to the public repo, I created a new branch and kept the changes there. When I finish the refactoring I can always push those to the public repo without having to worry much about what happened since I started the refactoring.
Because you keep a local copy of the entire history of the repository, any and all actions are extremely fast. No waiting for svn logs or slow commits, especially committing to Sourceforge from South Africa. With a DVCS you actually have control over your communication with the public repository server.
Of course, there are many more reasons, but I'll leave that for another rant. :)
Why git?
Playing around a bit with Mercurial, I eventually convinced myself to take the plunge and start using a DVCS. I still don't really know the difference(s) between Bazaar, Mercurial and git. My decision to go with git was based on the following advantages it had over the others, even before I began:
- I have a quick, local git reference guide: Wynand! He actually helped me understand a lot of the core concepts of a DVCS when I was working with Mercurial.
- Subversion integration. Our projects are hosted on Sourceforge's Subversion servers, so this is kind of a crucial point. git-svn came in and saved the day.
- Awesome tools. This is related to the first point seeing as Wynand is the one who showed me the git tools' awesomeness.
- Reputation. If it's good enough to be used for the Linux kernel, it must be good enough for a lot of other things.
Living with git
I've been using git for about 3-4 weeks now and it has been amazing! I admittedly only know about 10% of what a beginner git-user should know to use git effectively and already it has changed the way I develop software. Here are a few things that really stood out for me:
- git branches are cheap. As described above, branching in code in your local repo is not only super-useful, but also super-easy and extremely powerful. You can do just about anything across branches on the commit level: merging entire branches, cherry-picking specific commits to apply to another branch. The list goes on... and on and on.
- The git-gui tools. The two I have used most so far are git-gui blame and git-gui citool, the latter of which is something that has probably saved me hours already: Among its features, but most important to me, is the ability to easily select individual "hunks" (sections of a patch) that should be included (staged) in the next commit. Having a commit policy requiring as much atomicity as possible, this is a life-saver!
Conclusion
git allows you to do your development according to your own zen, whatever that might mean. If I had to summarize git in a few words it would be "powerful", "fast" and "control". Other DVCSs may very well have similar and/or better features, but I am, at least for now, happily ignorant thereof and content with using and abusing git. I would definitely recommend it to any programmer.
