It’s been a while that I wanted to try Git. At work, I’ve used CVS, Merant PVCS, MS SourceSafe and even the worst SCM ever conceived: Serena Dimensions. For the last few years, I’ve been using Subversion at work and at home, and it hasn’t been too hard. The only difficulties I’ve had with Subversion were all related to merging, and merge tracking. One of the few things you always hear about git is how branching is so easy, and how merging is a breeze. So I wanted to give git a try, even if the distributed nature of git has always seemed like a feature nobody cares about (at least in the enterprise).
First of all, I must mention the Pro Git book (freely available online), which does miracles in explaining how git works. But even with the help of the book, git has a learning curve. Fortunately, I’m not an early adopter, and git already has good support: msysgit and TortoiseGit work pretty well on Windows.
I’m only at the beginning and, unfortunately, I can’t use it on a medium-sized multi-developer project yet, but some of the aspects of Git already seem just right compared to SVN :
- In git, as far as I know, you can’t work on a subset of a project. A branch, a working copy, and every operation applies to the whole project. This might seem like a limitation, but it really simplifies things. For example, it avoids one of the annoying things in SVN: when someone merges a subtree, or even individual files, you end up with merge-tracking information being recorded on a whole bunch of files. Merging at the root of the project afterwards records new changes on all of these files, even if these files are not concerned by the merge. This can’t happen in Git. Another advantage is that you just have one .git directory, instead of one .svn per directory. Exporting the project tree is just a matter of copy/pasting. And there is no risk of accidentally copying the .svn files from one directory to another.
- The fact that a commit points to its parent commit seems so simple and right, and solves so many problems, that you wonder why it hasn’t been done before. Just being able to view the branches and the merges, in no time, in the log history, is really really helpful.
- And one of the killer features, in my humble opinion, is stashing. You’re in the middle of a change, and suddenly, you must fix an unrelated bug, as soon as possible. With SVN, my solution has often been to checkout a whole new working copy and fix the bug in this new working copy, in order not to interfere with (or loose) the unfinished work in the original working copy. With git, it’s really really simpler : you stash your unfinished work, switch to the branch where the bug must be fixed (if necessary), fix the bug, go back to the initial branch (if necessary), and unstash to find your working copy in the same state as before. Since the whole repository is available locally, this is really fast, and much more secure.