Git has made me more productive, and I will explain in a few words why that is. I could almost do it with twitter, but I like to take a little more time to make my point. The main benefit that git has given me can be found in performance of certain things I want to do when I am managing changes in my code base. The performance improvements of some critical parts of it are even so profound that they have changed the way I am working. In particular the fact that I can skip builds for most of my commits is a big time saver.
There have been many things said about git already and I suggest you use your favorite search index to bring yourself up to speed if you need to. Git is a simple distributed versioning system that is challenging many assumptions I had about development. Let’s go over these assumptions. I’ll show you my (svn based) assumption and why it doesn’t hold if you’re using git.
Work on one thing at a time
With subversion merging is messy, and because you want to tell a story with your commits, you cannot work on more than one thing at a time without checking out a full branch for each topic you want to work on. IDEA has a very cool workaround for this, called the Shelf, but with git the whole thing becomes a non issue. Because you do commits locally, you can work on many things at a time, make them work in concert and then commit them in several steps. Finally you make your build green again and push the whole story to a public place.
If this isn’t enough, you can (very cheaply) keep multiple local branches and merge them before you commit. More on branching later.
Never commit unless the build is green
You don’t want to look stupid and ugly, so you make very sure that before you make something visible to your team members, it won’t annoy the crap out of them. Untested modules, or code that doesn’t even compile annoys the crap out of smart people, so you don’t commit that…
I don’t know about you, but I need to run a build before I’m sure that everything is cool. Running a build on a typical project takes more than 5 minutes, if yours is faster, you’re one of the lucky few. The result with svn is that even a mundane trivial "i renamed this property" type of change takes at least 5 minutes. This makes you squeamish and triggers you to violate rules (until you look stupid and ugly and learn your lesson of course).
With git nobody knows what you’ve committed, until you decide to push, so you can be as stupid and annoying as you like and have just a single smart and thoughtful half hour in the day before you publish your changes. Everything you commit stays local and that is bliss. I usually batch up a commit or 5, then run my builds, check if I have my story straight and then push (once or twice a day). Git makes me commit more often and build less, which is a double win really.
Whatever you do, don’t branch
Subversion and cvs have taught me in several harsh lessons that branching is for people who are completely out of their minds. If you ever branch it is because you just did a release, and you should NEVER, EVER, attempt to merge branches. Ok, I know it can be done, I’ve seen it done, and yes, I’ve done it myself, but that were the three most horrible days in my life and the scars will never heal probably.
If I only ever used git and read the previous paragraph I’d be amazed and horrified at the incompetence. And having used git for a while I can’t believe I would tolerate the fact that branches are useless in svn for so long.
With these three assumptions utterly crushed I can move much faster. And the kicker is that there is git-svn so I don’t have to migrate any existing repositories to start working do the new beat. I noticed that where on a busy project I would normally spend at least 20% of my time dealing with version control or build misery, now that has been reduced below the pain threshold of 5%. Commits are also much faster, because I can postpone whatever merge conflicts I expect to a horizon where I have brain cycles to spare on them. I am not yet to a point where I share diffs with other developers, the way I’d usually send patches that were not ready to publish to the whole team, but if I get around to trying that in the field I’ll report back here.
My advice: try git and never look back, if you’re still on svn you should use git locally with git-svn because it will give you almost the same peace of mind.