in one of the repositories I work with some other folks on, we use pull requests as a way to manage our merges and sometimes we get merge conflicts (as normally happens). Here's the rub: other developers have been using the GitHub web interface to do the actual merges (in addition to just creating the PRs).
According to GitHub documentation:
Warning: When you resolve a merge conflict on GitHub Enterprise Server, the entire base branch of your pull request is merged into the head branch. Make sure you really want to commit to this branch. If the head branch is the default branch of your repository, you'll be given the option of creating a new branch to serve as the head branch for your pull request. If the head branch is protected you won't be able to merge your conflict resolution into it, so you'll be prompted to create a new head branch. For more information, see "About protected branches."
Sometimes this is not actually what we want. Here's why.
For example, let's say we're working on two feature branches:
feature/123
feature/456
And feature/123
is in staging
but not ready for master
.
And we want to merge feature/456
into staging
, so we create a PR, and it has merge conflicts.
If someone uses the GitHub web interface to merge that PR, what actually happens is as follows:
- GitHub will merge
staging
, which already contains work fromfeature/123
, intofeature/456
. - The user will resolve the conflict.
- GitHub will merge
feature/456
intostaging
.
Unfortunately, once feature/456
is ready for master
, when someone performs that merge, the code changes in feature/123
, which are still not yet ready for prime time, will come along with it into master
.
I'm 99% certain the idea behind this behavior is that GitHub wants you to resolve the merge conflicts in the head branch instead of the base branch, i.e., feature/456
instead of staging
.
Is there a way to have GitHub resolve the conflicts in staging
instead?