Sounds like you want to implement something like merge trains?[0]
[0]: https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-tr...
[0]: https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-tr...
E.g. when merging A, B and C. C might have no conflict with master or A but it has a conflict with B. Now for the queuing to work A -> B -> C it will have to know somehow how to patch C to fit on top of B.
Maybe B breaks if it is not working after merged into A, and then the queue becomes A -> C -> B (modified), now B probably needs a patch to merge cleanly on C?
But that's exactly my point. The first PR to merge cleanly will determine whether the next PR causes a merge conflict or not. At the time of merging, none of these PRs had a merge conflict.
We often have 10 conflicts between PR admission and approval.
And yeah, management won't do it. Fred Brooks wrote an entire book about this in 1975 that no one reads today and everyone would certainly ignore if they did read it. Because it tells you the unvarnished truth about the nature of communication and information flow within an organization. Such is the state of things in our industry. Sweet little lies.
I don't think a devops solution can remove those conflicts. At least not all of them.
If you have devs in the same hot-spots of the code, you're going to get conflicts. Maybe refactoring can address some of this core issue.
- the stage is always up-to-date with the target branch (so if it updates, we re-merge all topics on top of the new target branch head)
- topics should pass CI standalone before being staged
- the stage is first-come first-served, so "later" topics have to wait
- updating a topic puts it at the end of the line
- topics should really go through the stage before landing in the target branch
Our library implementing this: https://gitlab.kitware.com/utils/rust-git-topic-stage
However, given your later metric of 10+ conflicts per topic…I suspect your project is still in the "getting off the ground" phase where a stage is awfully heavy process because there aren't "bright line" distinct sections of the code yet. Or your topics are too big. Hard to say.