[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.