[BUG] When resolving a merge conflict on GitHub UI, the entire base branch of pull request is merged into the head branch. #52762
Replies: 8 comments 4 replies
-
+1 I didn't pay attention and this behaviour resulted in production bugs today. At least is there a way to disable that button? |
Beta Was this translation helpful? Give feedback.
-
@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 |
Beta Was this translation helpful? Give feedback.
-
This bug cost us several hours today. |
Beta Was this translation helpful? Give feedback.
-
Bumping this - how is this still not fixed? Fortunately it didn't affect production. |
Beta Was this translation helpful? Give feedback.
-
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! 😠 |
Beta Was this translation helpful? Give feedback.
-
Bro, how come this bug is still not resolved today? It's Mar 11 now, almost one year after this post |
Beta Was this translation helpful? Give feedback.
-
this is not a bug. this is how it's supposed to work. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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):
Expected branch history after conflict resolution:
Actual branch history after conflict resolution:
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:
git
CLI does through amerge
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.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.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):
Beta Was this translation helpful? Give feedback.
All reactions