No, WANdisco, Git does NOT promote anti-social development
Posted at 07:00 on 15 June 2011
David Richards of WANdisco has this to say about Git:
Funny, I was talking about this only today with an industry analyst and he has the same conclusion that we have. Git has its uses but probably not in the enterprise. OK please listen, I know that statement will upset a bunch of senior developers who think that GIT solves everything but it really doesn’t.
If you think about it GIT actually promotes anti-social software development; development in small, disconnected silos is not how software is developed in the real world. Most software is developed by teams whose members have a variety of skills who need to see what each other is doing and that’s the fundamental reason why GIT is not a threat to Subversion in the enterprise. It’s fine for the development of the Linux kernel but that model doesn’t work for most companies.
I’m sorry, David, but that is just wrong. It’s not just wrong in an existential sense, this isn’t just a Kantian viewpoint where you really need to consider what Schiller had to say on the subject, it’s wrong in the sense that 1+1=3 is wrong, or that the earth is flat is wrong, or that astrology is wrong. In other words, it’s just plain wrong. It is complete and utter FUD, it is a total misunderstanding of what easy, fluent branching and merging actually gives you, and it is totally detached from reality.
This argument, like every other anti-DVCS argument that you hear from Blub programmers and people who are being paid money to promote the likes of Subversion and TFS, boils down to, “These are the problems that you might encounter with DVCS if you don’t use it properly.” Compare that to the point that we DVCS guys make about centralised tools: “These are the problems that you are encountering because you can’t use it properly.” That is why Git and Mercurial are so popular these days among developers. They aren’t just a passing fad -- the traditional, line-based, centralised model simply doesn’t work.
Oh, and by the way, there are plenty of success stories of DVCS in the enterprise.
The fear that’s being promoted here is that people will use branches as an alternative to communication. In practice, that simply doesn’t happen with Git and Mercurial users. While there’s always a possibility that you’ll end up with wildly divergent branches that give you a Big Scary Merge, this is a problem that can easily be avoided and is in fact generally self-correcting in the long run. Once you’ve got a feel for the limitations to what you can achieve with branching and merging, you tend to work within, and adapt to, those limitations. It’s called “learning from your mistakes,” which is an essential part of agile software development (and if you’re not doing some flavour of agile, you’re doing it wrong).
On the other hand, centralised source control, with its restrictive line-based model, presents you with problems that are difficult if not impossible to fix. It forces you to make compromises in how often you check in code for starters. Siloed, anti-social development happens just as much in Subversion as it does in Git, and with far worse consequences, since the equivalent in Subversion is delaying checking in anything at all till your whole work item is complete. When this happens, you run the risk of losing hours if not days of work -- you end up with so many conflicts when you run svn update that you get confused and have to start over from scratch.
Before you start making a judgment about distributed source control, please do us all a favour. First, actually take the time to learn what you’re talking about. If you can’t explain to me what git bisect does, or what the tangled working copy problem is and why it’s a problem, or what a DAG is, or what the difference is between merge and rebase, then you’re not qualified to dismiss DVCS as unsuitable. It’s as simple as that. Then, actually try it out in practice on a non-trivial team project. Because again, if you are just going off hearsay rather than experience, you are simply not qualified to dismiss it as unsuitable.