You can’t always git what you want
I’m hoping some of us remember when subversion was first released. Those of us CVS users knew immediately that subversion’s changeset-based tracking was a big improvement.
Some of us held off a little while until the tool support had matured, but after a few months there was no great benefit to sticking with CVS, and subversion spread quickly. In a short time, it became the free source control system of choice.
Switching to subversion fixed a problem that with CVS, but it didn’t fundamentally change how we’d used source control as a team. That’s important.
The rationale for switching a team from subversion to git is less clear-cut and, I’m going to argue, you could end up affecting how your team works together for the worse.
Git is a more complex tool, but that’s not necessarily a bad thing, and I have no doubt it will get simpler tooling with time. Its speed is a huge improvement over svn and for some I’m sure sufficient reason to change. And, of course, it doesn’t drop pesky .svn folders all over the place. All improvements, straightforwardly.
But, if subversion is a team-based tool, git is designed around individual developers, loosely-connected in social groups. This distinction is what makes git an excellent social tool – an excellent choice for software developed by a diverse group of individuals as open-source projects often are. Just for the record, github rocks.
However, git’s group-development virtues are team-development vices.
Branching is an evil for small teams. Single-trunk development with continuous, often, easy integration leads to fewer bugs, better communication between team members, sharper code. I’d go further than most agile proponents here: if your team is small enough to handle it, this is what you should do; if it isn’t, it’s time to split the team.
On the softer side, the commitment that a team-member makes to keeping the trunk clean is important in itself. It’s these norms and commitments, personal promises and bindings that make the difference between a team and a group of individuals. And, our chosen tools are a part of that team structure.
Git is a gift for those people on your team who are not team players, but not necessarily a boon for the team. I’ve seen this play out a couple of times now, surely others have too?
So, what I think most teams would do better with is a subversion that’s faster and doesn’t leave .svn folders around, one that’s easy to set up and doesn’t have 200+ commands to play with. Perhaps if subversion were up on github we could all have a go at making it.
Leave a Comment
I'm Ben Griffiths:
I think this is absolutely right. The distinction between a co-located team and an open source project on Github is really important.
Although I share your disdain for branching, I think that branching for a release can be ok. Subversion doesn’t do a good job of tracking merges between branches, so it can be difficult to know whether a fix has been applied to both the release and the trunk. So I think this is another aspect of subversion that could be improved. However, I think the subversion folk are already on the case [1].
Anyway, a better solution is probably to make your testing and deployment so automated that you can release all the time – ultimately reducing the number of merges that need tracking to zero.
To my mind, branching is a type of technical debt [2] whose repayments can be deferred, but those repayments can quickly become unmanageable.
[1] http://subversion.tigris.org/merge-tracking/
[2] http://www.martinfowler.com/bliki/TechnicalDebt.html
I think you’ve got a really good point here – the tools you use as a team can directly affect how people work *as a team*.
I’d still like to have cheap, personal (i.e. not on the server) branches where I can toy around with ‘mad’ ideas and refactorings, but certainly not at the expense of a constant, single and easily-accessible point of truth (trunk) for everyone involved.
I also think there is value to be had in a consistent trunk that is always deployable but the nice thing about Git is that it’s flexible enough to twist it to your own workflow; I think there is a good compromise to be had between the centralized workflow of Subversion mixed with small, local temporary branches as James mentions.
The PeepCode git internals PDF has some good examples of using Git in different ways using different organisational and deployment structures.
Luke, I think you’ve missed the point about the trunk.
What matters in this case is not whether the trunk is deployable or consistent – although as you say there is clear value there.
Instead, I’m trying to make the point that in a software team the trunk should be what we’re all here to build.
What happens on the trunk is our shared work, our collaboration. We don’t all disappear into our own little worksheds, build things in isolation and then hope they all fit together; instead we all turn up at the same place and build the same thing together.
And, of course, this doesn’t scale to large groups, but equally the approach needed for large groups doesn’t scale down well to small teams.
Large groups need social, individual-based tools like git. It doesn’t follow that small teams benefit from them.
Of course, you can use git to have a strong single trunk workflow, but it doesn’t encourage that, make it easy, make it beautiful (to nod at DHH). And, that’s important, right?
I can’t be the only one who’s seen a drop in code quality and teamwork when git has been introduced, am I?
By the way, the svn team is now working on consolidating all the .svn/ directories into one location *outside* the working copy, just like distributed systems do. We’ve all used DVCS, and are learning from it.
I think that github really reenforces the negative “fork because I can” aspect of git. There are certainly way more forks of projects on github than on repo.or.cz. What’s the point of all these? For most contributors, it is enough have their own repo and to submit the occasional patch. But really, does everyone need to have their own PUBLISHed branch? Just use git send-email instead.