j.con
j.con

Reputation: 889

git - handling multiple pull requests that may have conflicts

I am using gitlab, and I have a protected branch. I have developers submitting pull requests for issues they are solving.

For a few reasons, I cannot merge the changes in immediately, and I want developers to continue working on the next issue.

What I foresee happening are unknown merge conflicts from the guidance I've given them. These are the steps I generally have the developers take when fixing issues for protected branches.

  1. Checkout and pull the protected branch
  2. Checkout a new branch labeled IssueA from protected branch
  3. Fix issues
  4. Submit pull request to merge IssueA into protected branch

Now they work on IssueB, starting at step 1. When they get to step 4 they have no conflicts and submit IssueB with no problems.

However, now as the merger I merge in IssueA and now maybe IssueB has a conflict (because the developer did not have IssueA merged in when starting at step 1.)

How can I resolve this without having to immediately merge in changes. I'm not sure if I should have developer merge in IssueA into their IssueB before submitting pull request. That doesn't seem right though because viewing IssueD for example and seeing so many other changes. Do I just reject IssueB, but I'd rather the developer fix conflicts while the issue was fresh in their mind.

Thank you

Upvotes: 0

Views: 96

Answers (1)

larsks
larsks

Reputation: 311318

In the situation you have described, it is common for the feature developer to be responsible for making sure their pull request is up-to-date with respect to changes in master (or whichever branch they are targeting in their pull request).

In a project with a number of developers working on overlapping files, you expect to see conflicts. It's a normal part of doing business.

Your developers should rebase their pull requests on master (or possibly merge master into their pr, depending on the workflow you prefer).

Upvotes: 2

Related Questions