Adventures with Git DVCS

26 July 2010

Over the last while I’ve been playing a lot with a distributed version control system (DVCS) called Git. In the last while, particularly with the presence of sites such as the excellent GitHub, Git has gained a lot of popularity and support among developers. Before anyone accuses me of “jumping on the Git bandwagon” – the bandwagon’s got a lot of momentum, and there’s good reasoning for that.

I’m not going to bore you with the detail of how Git and its distributed model works, there are plenty of excellent articles littering the web you can find with a quick search on Google. Instead I’m going to explain why I believe Git provides the best source control for teams.

With Git, every developer has the full repository available to them locally on their hard disk. While this means the initial clone of a large repository takes longer than an SVN checkout, it’s just about instant to perform any local operation – such as diff your entire tree (or any part thereof) or to add a new commit with no network connectivity needed. This makes it great to work in a totally disconnected environment, since the only operations that need network access are pushing and pulling code in other repositories.

The side effect of this incredible disconnected environment is that everyone is effectively on their own branch of the repository. As soon as I start writing a single line of code that diverges from the repository I cloned from, I’m able to commit on my local repository without anyone else ever seeing it. This means I can commit more often and in smaller chunks without breaking the rest of the codebase for the other developers on the project and getting flamed afterwards. Also once you realise you’re on a branch anyway, the mental barrier of branching out breaks down. In the last couple of weeks I’ve had up to 7 branches in my local repository.

Of course the other half of branching is merging and the Git developers have paid careful attention to the merge model. Even on medium size code bases (2000 files or so) it takes less than a second to merge a set of changes into a branch on my laptop.

Overall this freedom of branching and merging means that developers know they can do more with their code without the risk of stepping on someone else’s toes. If it works, great, merge the changes in. If it doesn’t work, just delete the branch.

I really like the freedom of workflow Git provides and the speed and robustness of it. I’m pretty sure that more and more enterprise users will take up on Git over the next year or so, particularly with the power provided by providers such as GitHub.