Can not merge pull requests after approval due to The merge-base changed after approval. #58535
Replies: 80 comments 43 replies
|
I ran into the same problem. In my case I had issued the pull request and requested a review from someone, then before they got to it I pushed a new commit removing some commented code. It seems to be related to these security enhancement changes: https://github.blog/changelog/2023-06-06-security-enhancements-to-required-approvals-on-pull-requests/. Since I am an org owner I was able to look at the branch protection settings and saw the setting in the image below. After I deselected this setting my reviewer was able to approve the PR and merge the changes. From the wording of the setting I think even with it enabled it should have allowed my reviewer to approve and merge the changes, since I made the later commit before he did the review. I think this is a bug. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
|
ok that cool message me to help you |
|
I also think this is a bug since closing the pr and re-openning it caused the issue to go away without changing any repository settings. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
|
Not sure if this will help anyone but I've just had this happen on a branch where I had branched off from an existing branch (didn't mean to do this......) and then the first brach was merged into master/main. This seemed to trigger the message appearing. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
This seems like intended behaviour, though: merging branch |
|
It looks like the pointer to the baseline branch is fixed in a PR, but then there is some process to check that sha. It fails because the baseline tip moved. You can edit a PR and change a baseline from e.g. |
|
This works for me! Thanks! |
|
This worked for me as well, I would recommend trying this as the first solution. |
|
This also worked for me! Thanks. |
|
|
Thank you very much, this works for me |
|
Also getting this happening:
|
This comment was marked as off-topic.
This comment was marked as off-topic.
|
We're hitting this now too. Strangely, I turned off the Dismiss stale pull request setting, and now the reviews aren't getting dismissed, but the PR still acts like no one has approved. Closing and re-opening the PR was the only thing that allowed us to move forward. |
|
Closing and reopening the PR did the trick, thanks! |
|
Yep, Closing and reopening the PR worked. Thanks |
|
This doesn't seem to work (anymore) |
|
Happens to me too. Auto-dismisses my review without any new code. |
|
Saw this as well with commits and PR created on Aug 7, 2023. As soon as a new review was added the review would be dismissed with the message
Closing the PR and re-opening it did fix the issue. We do have dismiss stale reviews enabled, but no new commits were added. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
We are experiencing this same issue. It requires closing and opening the PR, or having somebody with admin permissions to override the required approval. (Turning off dismiss stale approvals is not something we are willing to do) According to the git history, there were no commits that triggered this condition. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
I'm experiencing this as well. Can't find a rhyme or reason to it. I'll approve a pull and it will immediately be dismissed seconds later. There aren't any new commits being pushed. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
We are also seeing this. My PR is from my branch -> dev. The last commit to both master/dev was over an hour ago, and my last commit on my branch was over 30 minutes ago (I double checked). Every review said "Dismissed - The merge-base changed after approval."
|
This comment was marked as off-topic.
This comment was marked as off-topic.
|
In my case, I could merge my PR after adding members on the Collaborators and Teams page in Settings. Just FYI. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic, but actually this is exactly what worked for me. My colleague was able to approve my PR because he was part of the Organization. His approval was ignored until I added our Team as a Collaborator in the repo (which I missed earlier). His approval immediately got the green badge as well as the PR. |
|
Just a "me too" on this. A PR was stuck like this, pushed another branch name (of the same commit) and it approved and merged successfully. If anyone from GitHub actually wants to try to fix, I have left the "dead" PR open. Feel free to reach out. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Disabling the branch protection for "Dismiss stale pull request approvals when new commits are pushed" allowed us to get pass the message, "the merge-base changed after approval". This is a weird bug because nobody has made any new commits to our PR and it's annoying because it happens randomly. Any chance that Github Support can investigate this bug? |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Just another person on a team experiencing this bug! |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Problem: The message “The merge-base changed after approval” appears when a pull request (PR) is approved but cannot be merged because the base branch (usually main or develop) has received new commits after the approval. GitHub automatically blocks merging in this situation to ensure that the branch being merged is still compatible with the latest base branch code. 1 .Go to your local repo: 2.Pull the latest updates from main (or whichever branch you are merging into): git fetch origin 3.Resolve any merge conflicts if they appear.
git push origin feature/your-branch-name --force If you’re using branch protection rules, approvals may be dismissed after the base branch changes. |
|
@KrishPatel1905 - this is one thing that can cause this issue, but just to clear, there is another bug here, if you read through the thread (and I just ran into myself). Your solution is not a solution to the problem folks are having in this thread. Github clears even with nothing has changed since approval, in the base or anywhere else. I literally have a PR on a repo that no one is pushing anything to ... people keep approving, and github immediately clears with this message. |
|
Happened to our private repository today, closing & reopening PR then re-reviewed it seems to do the trick. Hope this get fixed soon |
|
This happens because GitHub invalidates approvals when the merge base changes. When new commits are pushed to the base branch (main, develop, etc.) after a PR is approved, GitHub detects that the PR was approved against an older state of the base branch. To prevent unsafe merges, GitHub blocks the merge and shows: “The merge-base changed after approval” Closing and reopening the PR forces GitHub to recalculate the merge base, and re-reviewing the PR gives a fresh approval against the latest base branch, which clears the warning. So yes — closing & reopening + re-approval works, but it’s more of a workaround, not the best practice. |
|
Welcome me to the club. Just faced this issue, had no answers to it. The only thing that helped was to change the base branch from |
|
Experienced this for the 1st time today. Nobody merged anything even, only created new branches. |
|
Faced this today. Closing and reopening didn't bring back the PR approvals thus didn't work for me. |
|
Pls fix this stuck with this |
|
We should close and reopen the PR. It should fix the issue. |
|
But Why Its show sometime until when we close and reopen ?? |
|
Yep, same here - I just got The merge-base changed after approval. message three times in a row, ended up force-merging my branch |
|
If the actual merge base hasn’t changed, that behavior can only be explained by stale or inconsistent merge-base recomputation inside the PR approval engine. To distinguish configuration from bug, run: If that SHA changed → expected security behavior. This is not solvable via CI or branch protection toggles. |
|
Better fix this soon! This bug gives a strongly misleading impression in 2026. Since the GitHub backend emits falsely attributed history events in the PR timeline it makes it appear the user is instantly rebasing and dismissing the review when in fact nothing of the sort is happening! But because it happens quickly due to github rules it looks like an AI Agent malfunction. In fact it's usually just github failing to ensure consistency because they haven't used Fable/Sol/Temporal properly yet on this high priority bug. This bug will wind up costing GitHub a lot of users if they don't fix it in 2026. |
|
For anyone still hitting this, I would separate three cases before changing branch protection settings. GitHub can legitimately require a fresh review when the effective diff being reviewed changes. That can happen even if the PR head branch did not receive a new commit, because the base branch moved and the merge base changed. To check the current state locally: git fetch origin
base=origin/develop
head=origin/your-pr-branch
git merge-base "$base" "$head"
git log --oneline --left-right --cherry-pick "$base...$head"If the merge-base SHA changes after approval, then GitHub is usually doing the safe thing: the reviewed diff may no longer be the exact diff that would merge. The harder case is when GitHub says the merge base changed but repeated local checks show the same merge-base SHA before and after approval. In that case I would collect evidence rather than repeatedly closing/reopening PRs: Also check these settings, because they can make the behavior look more surprising:
A useful diagnostic is to compare the PR event timeline with the Git refs: gh pr view PR_NUMBER --repo OWNER/REPO --json baseRefName,headRefName,headRefOid,baseRefOid,mergeStateStatus,reviewDecisionIf neither the base ref nor head ref moved, and For a Support report, the most convincing evidence is a pair of local |
|
I’m experiencing the same issue. The PR shows “The merge-base changed after approval” even though there were no new commits or changes to the base branch. Closing and reopening the PR seems to refresh the merge base and can restore the approval, but this feels more like a workaround than a proper fix. It would be helpful if GitHub could investigate why the merge-base is being recalculated incorrectly in these cases. |
|
I'm having the same issues. Just started today. |
|
Also had this happen today. did close/reopen to get it to stick |
|
We are also experiencing this issue |
|
|
ا |
|
We ran into this issue when we had a release branch based on main. A hotfix was merged ahead of the release branch and a merge commit was made from main to the release branch to include that hotfix in the release branch. When we tried to approve the release branch it would dismiss the approvals. Changing the base to any other arbitrary branch and back to main fixed the issue. Definitely looks like a bug. |
|
This issue occurs due to your repository's Branch Protection Rules or Repository Rulesets configuration regarding stale approvals. Root CauseWhen your feature branch is created and approved, it has a specific common ancestor commit with the target branch ( If another pull request is merged into How to ResolveOption 1: Re-approve after updating branch (Recommended for strict security)
Option 2: Adjust Branch Protection Settings (To prevent blocking workflow)If your team merges frequently into
|
|
In my, and I think others, experience, the steps you describe in Option 1 are insufficient. At least in some cases, and I think it is only some cases, you need to update your feature branch as you describe, then change the merge target, and then change the merge target back. |
Uh oh!
There was an error while loading. Please reload this page.
Select Topic Area
Question
Body
Hello
Yesterday we noticed that there is a weird message appearing when a PR is approved. We have a feature branch created from main and we are trying to merge it to develop. Once the PR is approved and required checks pass, we see this message suggesting that the merge-base has changed after approval, although it has not.
This has a significant impact on developer experience, so I kindly ask for your support/guidance.
Thanks
All reactions