Here are some more things I’ve noticed after a few more weeks with Git:
Many of the articles I’ve seen comparing the various different distributed versioning systems tend to complain that Git is overly complex. And while that may be, I don’t think it’s to the point where you can’t just pick it up and start using it. Back in May, when I first started using Git on a regular basis, I had only ever used Subversion, and I was productively using Git within an hour or two. Granted, I wasn’t using anywhere near all of the features, but at least I was back to where I had been with Subversion. On top of that, every now and then, I’ll pick up a new feature of Git, that either Subversion didn’t have, or I didn’t know about. Who knows, maybe this air of complexity is left over from the days of Cogito.
One of these new tricks I’ve picked up was stash. Git’s stash option gives you a way to put aside changes that you are working on, without committing or rolling back. This comes in handy when something you’re working on isn’t ready to be committed yet, but you need to make a quick change in something else. An example would be if you are working on a new feature, and all of the sudden realize that a small bug needs to be fixed in your test environment. Just ‘git stash’ to save your changes, and roll back your working environment to your current HEAD. Then fix the bug, commit the fixes and roll them out to test. After that, you just ‘git stash apply’ to re-apply your saved changes. And while I haven’t played with it much, another nice feature of stash is that git will save multiple stashes, and allows you to add comments to them so that you can more easily keep track of which is which.
I recently started a new job, which gave me a reason to look at my choice of VCS. I’ve been using Subversion for several years now, but being a UNIX admin by trade, I never really cared about my VCS, just so long as it did it’s job. For the most part, it has worked quite well, and I’ve never quite seen the big deal about distributed version control. I was always of the view that you store your code on your filesystem of choice, and that VCS is just for archival storage of the code. In the worst case, you used it to roll back a change that didn’t quite work out so well.
The new job was, not surprisingly, a Subversion shop, but I had started looking into a few DVCS’s out of curiosity. There was one part of my normal workflow that Made a DVCS quite appealing. My normal workflow when not connected to my VCS goes something like this:
- Write some code
- Get an off the wall idea that I may or may not want to use/save, and may not even work
- Copy off my current code base, usually as a tarball
- Work on new idea
- If it works, keep it, if not, restore from my copy
After a few weeks of working with code for 8 or more hours a day, I decided that there had to be a better way of doing things. Steps three and five always seemed cumbersome to me. That’s where the “distributed” part of DVCS appealed to me. What finally convinced me to try out a DVCS was the fact that instead of doing the usual, relativly long, process of copying off my current code base, I could now just do a fairly cheap branch, and be on my way. And when I was done, I could just merge my feature branch back into my main branch. Or, if it turned out to be complete junk, I could just delete the branch, and pretend it never existed.
For the curious, I chose Git as my DVCS, for one big reason. The Subversion interoperability provided by git-svn is head and shoulders above any of the other DVCSs I looked into. And since I have to check everything into a Subversion repository at work, this was a key feature for me.
