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