[carlmr]

Another question I got on this. What do you do with merge conflicts between the branches? Do you then provide the system with patches for the merge conflicts somehow, so that it can resolve them as needed?

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?

[Communitivity]

The developer whose task branch had merge conflicts was responsible for resolving the merge conflicts, and doing sidebars as needed where a discussion of the approach was warranted. They would resolve those conflicts in their branch before the PR was submitted. If the conflicts happened between submission and approval then the conflicts would still be resolved on the task branch before merge.

[carlmr]

>The developer whose task branch had merge conflicts was responsible for resolving the merge conflicts

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.

[deckard1]

The key is to reduce the number of developers touching a specific section of code, and line up all tickets and hand them over to a single developer (or two).

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.

[avisser]

> We often have 10 conflicts between PR admission and approval.

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.

[mathstuf]

We call ours the "stage". Merge conflicts are just a "please wait" signal. The way it works is:

  - 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

Conflicts (content or logical) will cause a topic to have to wait until the conflicting topic has landed in the target branch before it can participate in the stage. This usually only affects topics working in the same area.

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.