The benefits of using Git for source control

I was listening to the Hansel Minutes presentation about Git tonight.  Overall, it’s a very cool overview talk about Git and how it relates to development and existing source control systems.  A situation regarding local development came up during the talk that I’ve personally run into it on pretty much every project… 

With traditional source control (Subversion, cvs, vault, sourcesafe, etc), you checkin your modifications when they’re stable enough for other people on your team to consume.  Git adds the notion of a local repository.  So rather than having one central repository that everyone shares, each user has their own personal repository.  You can do all the checkins/checkouts/modifications/branches with your local repository, without affecting other developers on your team.  Then, similarly to traditional source control, you can push your changes to the peers (or primary peer – think of this as a stable repository on the build server) when things are stable.

To me, this is huge.  I can’t tell you how many times rewritten something, only to go back to the original method later…. or worse, lost changes.  With Git, you can checkin your changes anytime you feel like it and not worry about screwing up your coworker’s experience.  You get the benefits of source control, without the headaches of breaking the build for everyone else.

The guys that Hanselman interviewed from Planet Argon have their primary peer hooked up to Subversion.  So they can use Git locally, push their changes to the primary peer, which in turn commits those changes to Subversion.