So far in my time at SRT I have used both Mercurial and Bazaar, but I hadn’t gotten around to Git until yesterday. I finished the Git Immersion tutorial by Jim Weirich and would highly suggest going through it. There is a lot of good information in the lessons, even for those of us who are familiar with other distributed version control systems.
I think Git’s idea of tracking changes instead of files is a really cool way to think about source control. Change tracking instead of file tracking allows us to create much more granular commits, giving even more control over multiple versions of our source.
However, I think the way this is implemented in Git makes using it a bit more of a burden. Needing to add each change to a staging area does not feel like Git “getting out of the way until you need to deal with source control”. I have to either be constantly adding changes to my source control as I make them, or I have to figure out how everything should be committed after I’ve written the code. It also means that every time I want to add changes to source control I have an additional step to take over a more “traditional” source control system. I would much rather see an “opt-out” model of change tracking than an “opt-in” model. Most of the time, all of my changes should be taken together as a single commit. When I do have changes that should be separated into their own commit they are in the minority of the changes that I have made.
Currently, Git has not convinced me to convert from Mercurial, especially since I currently have a few repositories on BitBucket, but I think it is very worth while to know all of the options out there.
