Kevin Rohrbaugh

I’ve been flirting with Git for quite some time now, having installed and played around with it on my Mac after attending RailsConf 2008 and seeing all the interest and excitement around Git & GitHub. Unfortunately, most of my dev work is in .NET and Windows support in early 2008 was just getting off the ground so all I ever did was contract a healthy case of Git envy.

Fast forward to the present when I recently moved back to Windows 7 for my primary machine (from a Mac Pro), and the state of Git on Windows is greatly improved. So much that I’m switching to it for my personal projects.

Why Git?

There’s a lot of articles on the web about why Git is awesome, so I’ll just link to a few instead of regurgitating it:

• Introduction to Git: Distributed, fast, small, easy branching
• Fine. Git is Awesome: Compared against Mercurial
• Why Git Rules: Changing workflows

The main thing I love so far is the speed. Since local commits aren’t going over the wire, unlike with Subversion, they are fast. The speed really does make you commit more frequently. Since these commits are local, you can do them before you are done with a feature, since you’re not messing up anybody else’s codebase. These capabilities make it simpler to roll changes back should you realize your implementation isn’t quite cutting it mid-stream. Note that my impressions are based off basic use cases mirroring my SVN usage, without even tapping into the improved branching capabilities or pull request semantics that allow it to scale to large teams.

If you’re interested, the following list contains a few resources I’ve been using to get up to speed:

• learn.github.com: GitHub’s learning site
• git-scm.com: The main Git site with quick starts, cheat sheets and docs
• Git Magic: Git tutorials broken down into digestible chunks
• GitCasts: Screencasts teaching various aspects of Git
• Delicious ‘git’ tag: Popular Git resources on delicious.com

Git Options on Windows

Git functionality on Windows is primarily being developed through the msysGit project, which provides command line functionality like that found in Unix-based environments. The GUI-based projects discussed below tend to use msysGit behind the scenes, which is good since it’s an active project with regular releases tracking along with the main Git codebase.

Having been utterly spoiled by TortoiseSVN for years, I have to admit that I wasn’t all that interested in using Git from the command line for all of my version control needs. Dropping into a command line for some operations is fine, but I prefer the GUI tools for frequent operations (such as commits, pushes and pulls). Fortunately, Git GUI tools on Windows are progressing as well.

My currently preferred GUI option is Git Extensions, which provides an interface for many of Git’s commands, and includes Visual Studio plugins that make activating the UI a click away. The VS plugin isn’t quite as full-featured as something like VisualSVN, but it’s good enough. In general, Git Extensions has been the thing to enable me to switch from SVN for my personal projects.

There’s also TortoiseGit, which aims to port TortoiseSVN to Git, but I’ve had less luck with it (although I was using the 0.6 builds from May and haven’t tried the latest 0.8 releases) so you may also want to check it out. I plan to try this once again after I install Windows 7 RTM.

The GitHub Factor

While not actually part of Git, it’s necessary to mention GitHub within the context of this post. GitHub is a social Git hosting service that’s become popular within various open source communities. Ruby on Rails, Scriptaculous and YUI have all adopted it. There’s also been some interest in GitHub hosting within the .NET world, with projects such as Ninject and SubSonic moving their codebases to it.

For more information on using GitHub, check out the Hosting Your OSS Project on GitHub post that Aaron Jenson wrote back in March.

Wrapping Up

While I’m definitely a Git newb, I’m enjoying the tool so far. It’s not a hard sell for moving to Git from SVN, but perhaps that’s because I’ve never used any of the other distributed version control systems, such as Mercurial or Bazaar. The active and growing community around Git and GitHub swayed me toward it over these other options, but your mileage may vary. In any event, the time for distributed version control is upon us and it’s just another reason I’m glad we didn’t invest in Team Foundation Server at work.