I love Git. If you haven’t yet discovered the awesomeness of distributed version control, you are really missing out. Git is now the version control system of choice for a huge number of open source projects. That’s probably got a lot to do with GitHub, the best cloud based version control system on the planet, but the ease with which you can branch and merge with Git is also a major factor.
But even if you’re not building open source software development in the cloud, even if you’re stuck in some enterprise shop with TFS, you can still use the power of Git’s branching and merging to help you get your work done. Because Git is a distributed version control system it makes it trivial to set up a local repository. You can use that local repository create small local branches for particular features and to help you merge them together before you make a big check-in to your corporate VCS.
The trick to getting Git to work well in this scenario is to make sure that Git and your main VCS ignore each other.
For example, I’m still using subversion and Google Code for Suteki Shop. Yes, I know I should move it over to Git and GitHub, but I’m lazy and I quite like the Google Code project page, so I haven’t had the time or the inclination to do it yet. But I use Git locally to manage small changes. To get Git and subversion to ignore each other is pretty easy. Git places its repository in a folder in the root of your project called ‘.git’. I just ask subversion to ignore that folder. Using TortoiseSVN you do it like this:
Getting Git to ignore subversion is similarly easy. Subversion tracks its status using files in an ‘.svn’ folder in each folder under source control, so I simply add ‘.svn’ to my .gitignore file:
Here’s my .gitignore file:
I’m currently working on a stock control addin for Suteki Shop. While I was writing it I came across a bad design choice that I made in the past that stopped me from being able to properly decouple my addin from the core Suteki Shop project. Rather than executing a large refactoring directly in my stock control branch, I created a new branch from master, refactored away my bad design, tested it, merged it back into master and committed it to svn without having had to change or commit my in-progress work on stock control.
This ability to go off on tangents without one piece interfering with another is very powerful. It gives you the confidence to make very radical experimental changes that would have seemed like too much of a commitment previously.