[BUG] When resolving a merge conflict on GitHub UI, the entire base branch of pull request is merged into the head branch.

[MysticHLE]

Select Topic Area

Bug

Body

When resolving merge conflicts through the GitHub UI, the entire base (destination) branch (including the merge commit that is created from the conflict resolution) is merged backwards onto the head (source) branch. Context:

Given (commits numbered and represented chronologically):

• Base branch (target) with commits: C1, C2
• Head branch (source) with commits: C1, C3
• Conflicting changes between C2 and C3
• Create a PR to merge head branch into base branch, with conflicts to be resolved through GitHub UI.

Expected branch history after conflict resolution:

• Base branch (target) with commits: C1, C2, C3, C4
  • C4 is the merge commit with the conflicts resolved
• Head branch (source) with commits: C1, C3

Actual branch history after conflict resolution:

• Base branch (target) with commits: C1, C2, C3, C4
• Head branch (source) with commits: C1, C2, C3, C4
• C4 is the merge commit with the conflicts resolved

The expected behavior is such that the head (source) branch is unmodified. This said, I do realize that this is a documented behavior with a warning about this. However, I believe that this behavior is egregious and dangerous enough to be considered a serious bug that needs to be addressed with priority for the following reasons:

1. The behavior is completely counter-intuitive and unlike what the git CLI does through a merge command and resolving a conflict between current (base) branch and head branch. The end behavior of the conflict resolution through the GitHub UI as implemented is more accurately branch synchronization, and NOT branch merge. When I create a PR to merge changes from head branch into base branch, I expect that this is the ONLY thing it does. If I need to further sync these branches in the reverse direction, then it should be up to me to create another PR to do this explicitly.
2. The UI itself does not provide enough warning about this behavior. The UI should be intuitive to use and clear about such a dangerous behavior, and the developer should NOT be expected to read the warning about this behavior deep in the feature documentation itself. While the UI does have text indicating the direction of the merge in the conflict resolution process (and also in the final generated merge commit message), these tidbits are easily missed for the unsuspecting developer who expects things to work the same way as what they are used to in the command line.
3. The process of performing the conflict resolution in the UI and clicking on the Commit merge button actually modifies the remote head branch before the PR is even closed and before anyone can even provide feedback on the conflict resolution being taken. That is, the mere attempt to resolve the conflict creates side-effects in the original head remote branch. Even if the PR is cancelled at this point, this side-effect won't be reversed. This behavior is destructive and NOT apparent in the UI.
4. This behavior violates and muddies the core definitions of what head branches and base branches mean in the context of a PR. Note that when there are no conflicts, these definitions are honored. However, when there are conflicts resolved through the GitHub UI, this synchronization behavior makes it so that we can't concretely say which branch is the base or head anymore. This is made worse by the auto-generated merge commit message in the reverse direction as intended from the original PR for the conflict resolution commit - which is applied onto both the base and head branches.
5. This behavior makes the feature only usable for basic use cases of creating a local feature branch, pushing to remote, and then merging said change into main branch via PR. It is completely un-usable in use cases involving proper versioning and release management in which multiple remote branches are to be maintained together and merged from/to with potential conflicts to resolve while preserving certain isolation.

In the interim (whether this behavior will be changed or not), can the GitHub team please add a setting to disable this feature on the repository and branch level? That is, if there is a conflict detected (which the UI already does today), don't allow the PR to be created.

Multiple developers from multiple teams of ours ran into this issue, which unknowingly impacted our production environments multiple times because they expected the UI conflict resolution to behave similarly to the CLI. As it stands, we have to continuously try to educate and remind developers on our teams to avoid using this feature as it is dangerous and completely un-usable with our release process.

Screenshots highlighting the issues discussed above (generated from this repository):

[oguzgelal]

+1

I didn't pay attention and this behaviour resulted in production bugs today. At least is there a way to disable that button?

[yuriy-lentsevich]

@MysticHLE @oguzgelal you can try to disable "Resolve conflicts" option in GutHub UI by adding Ruleset - "Require a pull request before merging" for the head branch

[alek-womple]

This bug cost us several hours today.

[brenr]

Bumping this - how is this still not fixed? Fortunately it didn't affect production.

[SUMAR7]

Bumped into this today, a lot of WIP was about to go into production because of this, luckily we have an extra branch to gather all the changes that goes to production, it saved us but I was like WTH! 😠

[perryzjc]

Bro, how come this bug is still not resolved today? It's Mar 11 now, almost one year after this post

[lidiotduvillage]

wtf...

[GreedyA1]

this is not a bug. this is how it's supposed to work.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github

[MysticHLE]

Did you even read the entire post before commenting? I acknowledged the fact that this is documented behavior, but the mere act of doing so does not make such an unexpected, backwards, and intrusive behavior any less than a bug from the perspective of a Git user.

[GreedyA1]

depends on Git user I guess.

[r0bly0ns]

I'm sorry but there is no way that this is intended behaviour.

If you create a PR to merge Branch2 into Branch1 and there are no conflicts - all it does is merge the changes from Branch2 into Branch1. Any changes made in Branch1 stay there and are not merged into Bracnh2.

However, if there are any conflicts during the merge, why would the behaviour suddenly change to a bi-directional merge without warning?

This is clearly a bug

[lidiotduvillage]

I don't get how this could be unadressed for 1 YEAR now. Millions of users and such a counter intuitive and risky behavior ?! Seriously ? I don't get it.