Reputation: 889
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.
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
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