How to handle multiple PULL REQUESTS?

Question

Should I decline all PULL REQUESTS after the first one is accepted, so that hey can merge the accepted PULL REQUEST with their changes to be up to date ?

I have a problem around merging multiple pull requests. I'm working in VSTS.

Say I have a MASTER branch and I create two PBI's for two bits of work to be done.

For these PBI's I create a separate branch for each.

When the work is done on these PBI's, each person creates a PULL REQUEST to review before merging back to MASTER.

At the time of the PULL REQUEST, both branches are effectively up to date with the MASTER as they have merged the MASTER onto they're PBI branch.

Now when I accept one of the PULL REQUESTS and merge it down to the MASTER, the other PBI is now behind the MASTER branch.

Is it just a case of rejecting later PBI's and asking them to be made up to date ? And when they are made up to date, I accept them on a first come basis (as long as they're correct).

The problem I see with this is, if there are 'n' pull requests, I'm going to always have to reject 'n-1' pull requests as when I accept the first one, it leaves the rest out of date.

The image above shows the MASTER branch (green), and the two feature branches (orange and blue). Both havev made a PULL REQUEST, and when one is accepted, it leaves the other out of date.

Answer 1

First pull request approved, gets merged to the master branch first. Subsequent pull requests, don't need to merge master branch on their branch, unless there is merge conflict. So, they will not be out of date, unless they also worked on the same set of files.

When you see merge conflict on a pull request, straight away ask the developer to fix the merge conflict and update the pull request and work on reviewing pull request later. In this case, the subsequent pull request developer is out of date and he has to fix them in the merge conflict fixing.

So, whichever pull request goes subsequent to prior pull requests, have to take care of merge conflicts related issues.

Also if you use the Build validation policy in your branch policies you can set build result for the PR to expire immediatly if master is changed: This means that the build will be run again meaning you do not only catch merge conflicts but also errors that may be introduced by merging the PR with the updated master. Only if you have propper unit tests and have those enabled in your PR validation though.

Answer 2

You shouldn't need to worry about rejecting one or the other pull request.

After one pull request has been accepted, VSTS will show a big red error on the second pull request if it contains anything that conflicts with the items pulled in from the first one. This will prevent the pull request from being completed until the conflict is resolved.

I'm pretty sure you can even configure VSTS to email the person that created the PR if a merge conflict occurs so they can update the PR.

With a well structure application merge conflicts are not very common so this can be a good indicator of the quality of your application architecture.