I recently came across an msdn article about branching and merging and SCM
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?
Any other insight into this situation would be appreciated.