4 ms·

I fundamentally agree with your point: changing processes at large software teams is really, really hard, risky, and expensive. But if I may pick a nit about s

I fundamentally agree with your point: changing processes at large software teams is really, really hard, risky, and expensive. But if I may pick a nit about something I think you were describing as a potential process improvement, per-team branches have been tried at scale many times before, both with and without Git. Many smart people I know who've had to clean up subsequent messes believe, counterintuitively, that the larger and more complex you get, the more branches hurt you, because they encourage you to delay integration, and integration is painful. Git merge capability, while excellent, can't save you if two teams independently decide to rename a method that both rely on; that's still a conflict. I've heard of several other large shops relying successfully on toggles with a single mainline. Fowler describes this pain in terms of feature branches rather than team branches, but it's the same idea: http://martinfowler.com/bliki/FeatureBranch.html http://martinfowler.com/bliki/FeatureBranch.html Branching is a poor substitute for genuine modularity.

patio11 14y ago
I'll buy that -- I was just picking an example of a process tweak which sounded like a potential improvement that, absent scale, would be accomplished in two days with a project roadmap that would fit in a blog post.
Tloewald 14y ago
Nice article btw. The approach to integration recommended at the end seems exactly like something that might make the management of such a large code base easier.
alinajaf 14y ago
IME depends on what we're talking about. I've been at workplaces where we have multiple epic branches that diverge for three or four iterations at a time. In this scenario, it doesn't matter what VCS you happen to be using, integration is going to be painful and error-prone. More recently the branch and pull-request into master model has been working really nicely on a per-story basis, as long as people are considerate and mergeback from master before initiating the request. Overall though, I think the only branch that gets deployed anywhere should be master (or trunk if you prefer). Like you say, it's a terrible substitute for a system built of decoupled components.

patio11 14y ago

I'll buy that -- I was just picking an example of a process tweak which sounded like a potential improvement that, absent scale, would be accomplished in two days with a project roadmap that would fit in a blog post.

Tloewald 14y ago

Nice article btw. The approach to integration recommended at the end seems exactly like something that might make the management of such a large code base easier.

alinajaf 14y ago

IME depends on what we're talking about. I've been at workplaces where we have multiple epic branches that diverge for three or four iterations at a time. In this scenario, it doesn't matter what VCS you happen to be using, integration is going to be painful and error-prone. More recently the branch and pull-request into master model has been working really nicely on a per-story basis, as long as people are considerate and mergeback from master before initiating the request. Overall though, I think the only branch that gets deployed anywhere should be master (or trunk if you prefer). Like you say, it's a terrible substitute for a system built of decoupled components.