I resisted Git for a long time. It seemed a cultish thing with devout vocal followers and frequent mentions on Digg. I figured it would probably be a passing fad. I was wrong.

I drank the Kool-Aid and damn, it was tasty.

The first important thing to realize, especially when starting out and considering switching, is that Git works with existing Subversion repositories. That means the transition can be as simple as learning a few new commands, your repositories and servers don’t need to changing. Other team members don’t need to switch. If I had any other team members, this would be huge.

Of course, once you start using Git and see its potential, you’ll probably switch everything, convert your repositories and feel superior whenever you have to work with a Subversion hosted project.

Ultimately, Git is a revision control system and is fundamentally about preserving and protecting your working history. So feel free to experiment, it’s really hard to mess up.

It took me an afternoon to grasp the basic concepts of Git, or at least enough to use it in dumb-SVN mode. After about a week, I started to feel fairly comfortable.

I read a small mountain of weblog posts, documentation and the like, here are the ones I found most valuable:

• A tour of git: the basics
  Carl Worth’s port of Bryan O’Sullivan’s Mercurial book
• Learning git-svn in 5min
• HowTo: Use git for personal development when everyone else is using Subversion Part 1 and Part 2
• Using Git with Google Code Hosting
  A good overview for working with any Subversion repository.
• Bluish Coder: How to publish a Git repository Some good ideas about publishing repositories
• Git Quick Reference
• Fraser Speirs wrote this while considering switching from SVN to Git
• Git will eat Subversion’s Lunch by Bill Bumgarner

And definitely watch Linus Torvalds’ Google talk about Git. It won’t tell you how to use Git, but he’s funny and the talk worth seeing.

Getting Git

• Mac OS X Installation Binaries (other OS’s too)
• And of course, TextMate support: Git Bundle

While Git itself is easy to compile from source, getting the documentation manpages built on Mac OS X Leopard is a pain in the butt. I futzed around with it a little, but gave up halfway through installing a seemingly endless line of dependencies. The Mac binary installer works perfectly well and is kept up to date. I’d rather spend my time using Git than installing it.

Using Git

I was blown away by some of the stuff Git can do.

In the Google talk Linus pointed out how all SCM packages could do branching and branching wasn’t a problem. Merging was. Merging branches with Git is leprechauns and unicorns. It’s almost too easy. After a few days I found myself branching all over the place, constantly creating new branches to test any idea I was having. Folding those branches back in was almost always quick and painless.

Interactive line-by-line commits mean it’s possible to commit single lines from a file instead of the whole thing. This is great if you happen to go off on a bender and change a zillion different things between commits.

Cherry-picking is also great, and saved my butt when I created a pretzel of branch history. Using git-cherry-pick I was able to straighten out my history completely within Git using Git’s tools with no loss of work.

Conclusion

I started writing this post at the end of May, it’s now early July and I’ve been using Git for a few months with no regrets. The only time I hold my breath is when I’m pushing changes back to SVN, though it hasn’t glitched on me since early June. The speed and flexibility of Git are a constant pleasure to work with. The pain of merging branches, which used to take entire afternoons with SVN, has almost become an afterthought.