Etydhv

I recently came across an msdn article about branching and merging and SCM

article: https://docs.microsoft.com/en-us/previous-versions/aa730834(v=vs.80)

In the article they say 'big bang merge' is a merging antipattern:

Big Bang Merge — deferring branch merging to the end of the development effort and attempting to merge all branches simultaneously.

I realized that this is very similar to what my company is doing with all of the development branches that are produced.

I work at a very small company with one person acting as the final review + trunk merge authority. We have 5 developers (including me), each of us will be assigned a separate task/bug/project and we will each branch off the current trunk (subversion) and then perform the development work in our branch, test the results, write documentation if necessary, perform a peer review and feedback loop with the other developers, and then submit the branch for review + merge on our project management software.

My boss, the sole authority on the trunk repository, will actually defer all of the reviews of branches until a single point in time where he will perform reviews on as much as he can, some branches will be thrown back for enhancements/fixes, some branches will merge right into trunk, some branches will be thrown back because of conflicts, etc.

It's not uncommon for us to have 10-20 active branches sitting in the final review queue to be merged into trunk.

We also frequently have to resolve conflicts in the final review and merge stage because two branches were created off the same trunk but modified the same piece of code. Usually we avoid this by just rebranching off trunk and re-applying our changes and resolving the conflicts then submitting the new branch for review (poor mans rebase).

Some direct questions I have are

Are we exhibiting the very anti-pattern that was described as the 'big bang merge'?

Are some of the problems we're seeing a result of this merge process?

How can we improve this merge process without increasing the bottleneck on my boss?

Edit: I doubt my boss will loosen his grip on the trunk repository, or allow other devs to merge to trunk. Not sure what his reasons for that are but I don't really plan on bringing the topic up because it's been brought up before and shot down rather quickly. I think they just don't trust us, which doesn't make sense because everything is tracked anyway.

Any other insight into this situation would be appreciated.

Some suggestions:

• There is nothing wrong in having a lot of feature or bugfix branches as long as the changes done in each branch are small enough you can still handle the resulting merge conflicts in an effective manner. That should be your criterion if your way of working is ok, not some MSDN article.




• Whenever a branch is merged into trunk, the trunk should be merged into all open development branches ASAP. This would allow all people in the team to resolve merge conflicts in parallel in their own branch and so take some burden from the gatekeeper of the trunk.




• This would work way better if the gatekeeper would not wait until 10 branches are "ready for merging into trunk" - resolving merge conflicts from the last trunk integrations always needs some time for the team, so it is probably better to work in interwoven time intervals - one integration by the gatekeeper, one re-merge by the team, next integration by the gatekeeper, next re-merge by the team, and so on.




• To keep branches small, it might help to split larger features into several smaller tasks and develop each of those task into a branch of its own. If the feature is not production ready until all subtasks are implemented, hide it from production behind a feature toggle until all subtasks are completed.




• Sooner or later you will encounter refactoring tasks which affect many files in the code base - these have a high risk of causing a lot merge conflicts with many branches. Those can be handled best by communicating them clearly in the team, and make sure to handle them exactly as I wrote above: by integrating them first into all dev branches before reintegration, and by splitting them up into smaller sub-refactorings.




• For your current team size, having a single gatekeeper may still work. But if your team will grow in size, there is no way around having a second gatekeeper (or more). Note I am not suggesting to allow everyone to merge into trunk, but that does not mean only your boss is capable of doing this. You will probably have one or two senior devs who could be candidates for doing the gatekeeper's Job, too. And even for your current team's size, a second gatekeeper could make it easier for your team to integrate to the trunk more often and earlier.

Are we exhibiting the very anti-pattern that was described as the 'big bang merge'?

Sounds like it.

Are some of the problems we're seeing a result of this merge process?

Definitely

How can we improve this merge process without increasing the bottleneck on my boss?

At my company, every dev has the ability to merge. We assign a Merge Request to another dev, go through the review/feedback/update cycle until both parties are satisfied. Then the reviewer merges the code.

10-20 branches waiting to get merged is a sign that your process is flawed. If we had that many, all dev work would stop until it was cleared up.

This is essentially how a lot of open source projects work, including most notably the Linux kernel, which has a lot more branches in flight than you do at any given time. The typical way to avoid big bang merges in these projects is to create another branch (or multiple branches) for continuous integration. This is the branch you use to make sure your changes work together with your colleagues, and it gets periodically rebased onto the trunk when the gatekeeper gets around to doing reviews.

Optionally, you can use this branch to combine several of your own pull requests into one big cohesive request for your boss to review. Linus Torvalds typically gets pull requests that have been integrated two or more levels deep, and can have a size on the order of, for example, a complete new filesystem driver.

So you have 20 branches. Branch 1 is just merged. Then the developer of branch 2 has to merge branch 1 into their branch to be able to merge into main without conflict, then merges. Then the developer of branch 3 has to merge branch 1 and branch 2 into their branch to be able to merge into main without conflict, then merges.

Exercise for the reader: Write a program that prints my complete post :-)

This is madness. You will be spending an incredible amount of time merging.