Archive for July 2008
Git Isn’t Social
I enjoy using Git for my personal projects. I’ve always been a big fan of handling changes and exploring implementation ideas in branches rather than a project’s trunk, so Git fits my personal development workflow nicely. That said, for team projects I would choose Subversion over Git in a heartbeat. Every time.
I continue to be astounded that the community believes Git to be more social than centralized VCS like Subversion. I guess the notion is that Git makes the following scenario reasonable:
Persons A, B, and C are all working on a project. Person A is the project owner and controls the official source code repository. Persons B and C are working on changes that are of interest to each other. With Git, Persons B and C can exchange updates easily without Person A’s knowledge or permission.
This is valuable in OSS development where a central official project leads to multiple, “flavored” products. RedHat and Novel each provide their own product based on the Linux kernel. IONA provides its own product derived from Apache projects for EAI/SOA. Relating this to my example above, we would expect that Persons B and C may each be releasing their own products based on Person A’s project. There exists a many-to-one relationship between products and projects.
However, most projects do not follow this pattern. Most projects—especially outside of OSS—produce a single, official product. In this scenario, Persons A, B, and C are all on a team working on the same product. Now the communication between Persons B and C no longer looks like positive community collaboration—it looks like coding in isolation. Perhaps B and C work a different office (or different time zone) than A or maybe B and C simply don’t like working with A. In any case, they aren’t collaborating with a team member on a team project. Coding in isolation and the consequent big bang integration is a long-standing and obvious software development anti-pattern. And Git encourages it.
Ben Collins-Sussman discusses this aspect of DVCS in depth several times. I should note that I acknowledge the problem I highlight as fundamentally a social problem, not a technical one, but I agree with Ben’s assessment that “even though one shouldn’t depend on technical solutions to social problems, default tool behaviors matter a lot”.
