Depending on your tools and practices, version control can be either burdensome or liberating. At my first programming job, they – gasp – didn’t use version control at all. CVS was the first system i learned how to use, and it changed the way I worked. Looking back, CVS was pretty horrible, but compared to nothing, it was pretty spectacular. At another job, I lead the charge in conversion from CVS to SVN, which was more evolutionary than revolutionary.
The thing I learned during that is that tools that are so integral to how everybody works are not easy to replace. Many people would rather use something that’s holding them back than learn something new. There’s also the issue of stability, maturity, and workflow integration. Being generally pleased with Subversion, and it being so well accepted now, I’d become skeptical of all of these new hotness systems all the cool kids had started using. I figured that, even if they’re marginally better in the way that SVN is better than CVS, it’s not worth the battle.
Last year, I was working on a contract for a company that used git. I bought the very excellent Peepcode introduction to git and was immediately floored with what I saw. Git has changed the way I work in a manner as significant as moving from file based version control to CVS. There’s a new freedom to quickly experiment or completely change directions without the fear of the merge.
Today, I manage a codebase that always has several simultaneous lines of development. I feel more agile. I’m more willing to take on large refactoring projects without fearing what will happen if they’re interrupted by some other task. Since it’s so easy to setup a local repository (git init), a much larger percentage of things I work on are versioned. Features like stashing and partial file commits make it easy to switch context without fear or losing work or dirtying commits.
If you haven’t tried git yet, you should. Take 45 minutes and watch the Peepcode video. You can easily create a shared repository on github. Give it a try.
