Pull requests and merge conflicts

[paulcr]

My organization currently requires developers to submit pull requests to have them reviewed by a small group of "gatekeepers". Once the pull request is finished and tested it is merged by the gatekeepers into our develop branch.

A problem we're having is that it's difficult for the gatekeepers to work through merge conflicts without taking the conversation out of the pull request. Is there a way to communicate diffs back and forth to work through merge conflicts in the pull request?

[patrickmckenna]

@paulcr Great question, but tough to answer quickly. Are you using Pull Request comments, e.g. making line-level comments, commenting when you push up new changes to a branch (which the PR will reflect), &c.?

[patrickmckenna]

Git (and GitHub) of course keep a full history of the project, too, so you can always view the code in any past state. And the Pull Request will automatically reference any new commits to the branch, e.g.

[paulcr]

Totally understand... when a feature or bug branch diverges too much from our develop branch we need to merge develop into the feature/bug branch. When merge conflicts arise we're looking for a way for the gatekeeper to communicate the conflicting lines to the developers involved to help the gatekeeper work through the conflicts.

We do use PR comments and line level comments but since the conflicting merge can't be pushed we can comment

[patrickmckenna]

@paulcr Wait, only the gatekeepers get to see merge conflicts?! They're not exposed to whoever wrote the code?

[patrickmckenna]

Do you use any CI tools?

[paulcr]

We would like a way for the gatekeepers to present the merge conflicts in the PR so that the developers responsible for the change can work with the gatekeeper to resolve the conflicts.

No we currently aren't using any CI tools.

[patrickmckenna]

@paulcr Before opening the PR, are you attempting the merge locally? That's always good practice, and will of course show you any conflicts. (Instead of doing the merge to master, just create a new branch off master, e.g. merge-test-master, and merge into that.)

[paulcr]

No. The process is currently:

1. Developer forks a feature/bug branch from the develop branch
2. Developer completes work
3. Developer pushes branch to remote
4. Developer opens a pull request to develop branch from their bug/feature branch
5. Gatekeeper reviews the pull request
6. If changes need to pulled in to feature/bug branch from develop branch for additional testing then Gatekeeper does the merge.

At this point if the merge is successful the Gatekeeper asks the developer to retest their bug/feature. If the merge from develop is unsuccessful due to merge conflicts then the conflicts need to be resolved. The Gatekeeper will need feedback from the developer(s) responsible for the conflicting lines. Currently we do this offline via meeting/skype but we'd like a way to communicate the merge conflicts in the PR so Gatekeeper and the developer(s) can resolve the issue together and the organization gets an audit trail detailing the resolution of the issue.

[patrickmckenna]

Developer forks a feature/bug branch from the develop branch

Do you mean you open a new branch on your fork of the canonical repo? Forking and branching are two distinct operations.

[paulcr]

Sorry yes... they open a branch. We use a shared repository model.

[patrickmckenna]

@paulcr Did that help?

[paulcr]

@patrickbm no sorry that doesn't really resolve the issue for us. We just started using pull requests so it's probably more of a process issue internally in the organization that need to be resolved.

Thanks for the help and suggestions.