How do you agree on a branching strategy in your organization?
I’m obviously asking about the branches in your favourite version control software. The strategy can be quite different depending on which software you are using. In Git you might not even realize that you have created a branch while in ClearCase you have to understand how to write a config-spec to be able to do the same thing. But regardless of how hard or easy this is, we often end up with the same questions. Should all teams work in the same branch or should we use separate branches per team/feature?
In large organizations the most common way of handling this seems to be to create separate branches for every feature. This will allow all teams to work on their features without being disturbed by what is done by other teams. But this also means that they don’t know if the file they are currently updating still exists in the main product branch. This may sound like a situation that is fairly uncommon and I think you are right. But I have seen several examples where a new feature in a large system takes several months to complete. When the time for release approaches many features wants to merge to the main product branch at the same time.
And now the fun begins…
If you’re lucky, you will be the first team to merge to the main branch. This step is easy. But all other features are now in trouble. They first have to rebase/pull the latest changes to be able to verify that their changes are still compatible. If you have been working for several months while ignoring changes done by others, the risk of clashes between change sets is quite high.
A common way to handle this is to spend several weeks to integrate the different features. Once this is done an extra period of “stability testing” ensues to make sure that we didn’t mess up something in integration. I have seen new features being thrown away when, after months of development, they find that the state machine they depend on has already been replaced with something else. Months of work is wasted in a never-ending game of catch up.
But what is the alternative?
You can let everyone work in the same branch. Instruct everyone to run all the relevant tests before they check in to make sure that the branch is always stable. No more merges from hell and life is good… almost…
If you manage to work this way, then that is great!
But too often, this way of working does not live up to expectations. Especially in large complex systems with legacy code where many teams are involved. There must be a way to share code between developers without having to check it in the main branch. True, you can do changes in a way as to not affect legacy behaviour, but thing do go wrong sometimes. With many teams involved, this “sometimes” seems to happen quite often.
There’s also another reason why you don’t want to work directly in the main branch. I have yet to see a developer who writes the correct and final solution in the first try. At least for something that requires more than a few lines of code. Trying out different solutions is a common way of working and you often want to check in intermediate changes to easily go back to a previous state if you need to try something different.
In Git you always get your own private branch where you can check in unfinished code. You can even share commits directly between developers without going trough the main branch. But this should be an exception to the rule. With many developers, this way of sharing becomes unmaintainable. Having a team branch or a branch for a specific feature might still be necessary to be able to cooperate in a team.
But this takes discipline. When the deadline approaches, a common reaction is to focus on what you or the team have to accomplish. The short-term solution is often to stop “wasting” time on frequent synchronization between the feature branch and the main branch. Let’s do it all at once in just before delivery instead. And now we have reinvented the problem we tried to solve in the beginning…
I think the solution to this is education. Making people aware of the consequences of this way of working can go a long way to fix this. But this does not only apply to the developers. The managers and project leaders must also understand this to avoid situations where they try to order the developers to stop wasting time on “meaningless” tasks.
Leave a Reply