Git, reconsidered

I’ve expressed my skepticism before that DVCS (distributed version control systems) like Git offer a lot of benefits over traditional version control systems like Subversion. I’ve had the opportunity to use Git exclusively for quite a few months now, and have had the opportunity to appreciate its benefits. My opinion on this matter is somewhat tempered now. Here are my current thoughts on this.

Souring on Subversion

One thing that has made me lean more positively towards Git is that Subversion’s warts have become more apparent to me over time. And they are not going away any time soon. For example, the convention-based approach to branching and tagging or the ability to do subtree merges makes it all too easy to paint myself in a corner. There is still no real support for moving/renaming (WC tracking does no count). These are not weaknesses inherent in centralized VCs, but they are glaring weaknesses found in the dominant centralized VC, Subversion.
What is most frustrating, however, is the abysmal pace of Subversion progress. When I last blogged on this subject, I pointed out items on its roadmap that would gain some of DVCS’ features: shelving and checkpointing. That was in 2010. It is now 2014, and these features as well as much-requested features like rename tracking and improved merging remain deferred far out into the distant future. If you want to use Subversion, you should be prepared to appreciate it in its current state, because it’s not going to change much over time.

The Github experience

I had assumed that Git’s advantages was only in its distributed nature, the D in DVCS. Consequently, while that might be great in distributed environments like the Linux kernel development for which it was invented, I did not think it would be useful in a typical commercial environment. After all, we wanted a central location for our code, don’t we?
As it turns out, Git works great in a CI pipeline environment: code could be qualified and promoted to different repos as it is deemed ready. Moreover, Git on Github (and similar services) offers something hard to do with plain Subversion: an integrated, structured code review process. The ability create pull requests that team members can view, comment on and selectively merge (if you are authorized) opens up team interaction possibilities not previously possible under the old model. This team code review facility is the single biggest draw for me.
While the Git command line is cryptic and the changeset IDs remain opaque, I’ve found that TortoiseGit has smoothed the learning process for me. Its similarity to TortoiseSVN has made the transition much easier for me.

It’s not all roses

But Git continues to have its rough edges, and they remain rough over time. For one thing, the conceptual complexity of a DVCS remains. Consider what it takes to get your changes into the Subversion repo:

1. Update
2. Commit

Consider the steps invlved when you have distributed Git:

1. Stage
2. Commit
3. Fetch
4. Merge
5. Push

If you also use the pull request/review feature on Github, it is even more complicated:

1. Stage
2. Commit
3. Fetch
4. Merge
5. Push
6. Pull request
7. Merge (on Github)

Git is supposed to be good at merging. It needs to be, because with a DVCS you basically have to merge all the time. Merge conflicts are more frequent: it’s not uncommon to see my pull request become unmergeable because someone merged a conflicting changeset. Unlike a simple VC, the distributed nature of Git means more changesets are in flight.
Unfortunately, some people struggle with merges. I’ve seen colleagues waste a ton of time struggling with merge issues. And their struggle can quickly become your struggle when a botched merge or someone doing a “push –force” causes the shared repository to seemingly lose a week’s worth of the team’s commits. Oops, time to call our Git guru. It can be rough going for people who would rather expend their brain power on their code rather than their tools.
Someone has said (paraphrasing roughly) that Git is sort of a Swiss army knife with a live chainsaw and many sharp pointy edges attached. I heartily agree. I’d summarize my attitude towards this powerful tool as follows:

Git makes easy things hard and hard things possible.

Related links

My previous blog posts on the subject:

• DVCS for all the wrong reasons
• DVCS vs Subversion smackdown, round 3