Rebase and merge is blocked incorrectly?

[brettiegabber]

Hello,

My team is relatively new to GitHub and we have been experiencing an intermittent issue.

Our repository requires linear history and we only allow the rebase and merge option for pull requests. It is a large repository and sometimes PRs are merged every 5-10 minutes or so throughout the day. Usually the rebase and merge process works as expected. Occasionally, however, the rebase and merge button is blocked/greyed out and GitHub has a message saying "This branch cannot be rebased due to conflicts."

When this happens, there are no real conflicts and a local, manual rebase from main will always complete without incident. Usually there is no crossover whatsoever amongst the files involved.

After performing a manual rebase locally, and then force-pushing to the PR, we sometimes have the message clear but sometimes not. It seems to us, anecdotally, that any other PR merging to main between when we rebase and when we view the PR will trigger the blocking message "This branch cannot be rebased due to conflicts." For some reason, the ability to automatically rebase and merge just never functions at all with certain pull requests.

We cannot figure out why, in most cases, GitHub is able to automatically rebase and merge even when there are later commits to main, but on some specific PRs we simply cannot get this to work and have to manually rebase, push, and then quickly click rebase and merge before the main branch is touched again.

Does anyone have any thoughts on this?

Thanks,
Brett

[ryanwong-metropolis]

We just observed the same symptom, too.

I verified that the merge conflict is only observed by GitHub; it's not reproducible on development laptops using git command-line. Both merging master into the PR branch, and merging the PR branch into master, works cleanly without conflict when using git command-line.

The git command line version I'm using is git version 2.25.1

I tried the following workaround, and it seemed to work. First, rebase master and then squash the PR branch (so that the PR branch is only one commit on top of the latest master), then force push. If this doesn't resolve the GitHub false merge conflict, try create another branch with the same content (commit), and push that new branch and open a new PR. I see that the false merge conflict on GitHub goes away with this new PR.

[RubenGarcia]

I am also affected

[alinooshabadi]

I'm encountering a similar issue. Everything functions correctly in my local environment, but the problem only arises when using the GitHub UI.
My local Git version is 2.32.0.

[banditopazzo]

I ran into the issue too

[KalleRaiskila-synthara]

Getting this too.
My hunch is that it happens when the rebase would skip already existing commits from the target (develop) branch.
This happens when I start my_feature_branch not from a clean common develop branch, but rather from some_other_feature_branch, and the some_other_feature_branch gets merged into develop.

I.e. on the command line I get a warning like this.

$ git rebase origin/development
warning: skipped previously applied commit 0326df8
warning: skipped previously applied commit e55d2cf
hint: use --reapply-cherry-picks to include skipped commits
hint: Disable this message with "git config advice.skippedCherryPicks false"
Successfully rebased and updated refs/heads/my_feature_branch.

Maybe GitHub's rebase functionality interprets those warnings as errors?

[AshleyT3]

Getting this too.
My hunch is that it happens when the rebase would skip already existing commits from the target (develop) branch.
This happens when I start my_feature_branch not from a clean common develop branch, but rather from some_other_feature_branch, and the some_other_feature_branch gets merged into develop.
...
warning: skipped previously applied commit 0326df8
warning: skipped previously applied commit e55d2cf
...

Have you confirmed that theory by reproducing the issue? In my testing the appearance of dropped commits (i.e., the message "skipped previously applied commit") on rebase does not have a direct correlation to the issue. Dropped commits can happen where the issue does not occur.

For example, if I do the following:

1. From a sync'ed main: git checkout -b mybranch
2. From mybranch, modify/stage files then git commit.
3. git checkout main
4. Get the commit from mybranch: git cherry-pick <commit_from_mybranch>
5. git checkout mybranch
6. git rebase main

In step 6, I will see the dropped commits which is expected by default. If mybranch is a PR branch, and I push its commit from main (not from mybranch, but with mybranch's commit now in main, if I push from local main to origin/main), the PR branch remains Open but can be merged... there is blocked indication.

The issue is about an inexplicable block which does not deterministically occur by the mere presence of PR branch rebase dropping duplicated PR commits.

If you have steps to recreate the issue, it would be great to know about them... I've not been able to recreate it... without any steps, I'm left concurring with OP that it is an some apparent intermittent GitHub issue affecting PR integrity.

[KalleRaiskila-synthara]

I have not seen this problem since reporting it.
Earlier I saw it only twice, the occasions maybe about a week apart.

I tried to reproduce it now too, but now I cannot get even those warnings locally.
I'm sure I do the same steps, but on rebasing on the command line I get:

dropping 5331018bd7471b2ce5f754d60374374d900f31da Squashed commit of the following: -- patch contents already upstream
Successfully rebased and updated refs/heads/branch2.

instead of

warning: skipped previously applied commit e55d2cf

So I guess I am doing something differently now compared to earlier. I just can't figure out what.

[KalleRaiskila-synthara]

Problem is popping up again. And consistently, I am seeing a
warning: skipped previously applied commit 568b874 when rebasing on the command line.

For some reason, I cannot get this warning to reproduce on a public repo :(

[eywolfe]

My team is still running into this issue sporadically when opening a PR that merges staging into main. We select "rebase and merge" when merging these PRs. Sometimes new PRs open without issue but sometimes we get the error that the branch can't be automatically merged because of conflicts.

We weren't able to open a PR merging staging into main today because the button was greyed out. When we created a duplicate branch staging2 we were able to open a PR but it had conflicts. Locally the rebase succeeds without any conflicts but did have some skipped commits as @KalleRaiskila-synthara described above. We were not able to merge this PR with the rebase and merge strategy because Github said said the PR could not be rebased safely. The issue doesn't arise every time we have skipped commits but I think has only happened when we have skipped commits.

Our workaround has been to reset main to match staging (and force push to main 😢) so the commit shas are the same. That solves the problem for at least one deploy but we somehow end up in this state again. I've used the rebase and merge strategy for releasing to main in the past without any issues. Not sure what's different here, but the fact that it works locally and not on Github makes me think something has changed.

[fgiloux]

In my case the explanation was here

Merging a pull request using the "Rebase and merge" option is limited to 100 commits. If you have a pull request with more than 100 commits, you need to create a merge commit, squash and merge, or split the commits up into multiple pull requests.

[svenzik]

Thank you @fgiloux, I just ran into the same problem. I needed to merge two repositories and that caused PR to have more than 100 commits. I need to keep the history and I will split my commits between PR.

Github shows an error: This branch cannot be rebased due to conflicts
You can also merge this with the command line. View command line instructions (link)

Not singe detail about the actual reason. Github team, please add a clear reason to the error message. It would have taken me ages to find out the real reason, if there would not have found the previous comment.

[qmonnet]

Same thing here, and indeed a clear error message would help! Thanks @fgiloux for figuring it out 🙂

[jrodden1]

+1 from me as well.

I had a branch that had 202 commits on it and got the same generic error message of This branch cannot be rebased due to conflicts and the grayed out Rebase and Merge button.

I was getting this even though it showed I had no conflicts and should have been good to do the rebase & merge. 🤔 (huh?)

When hovering over the grayed out button, a popover showed Merging is blocked due to failing merge requirements which wasn't super helpful and sent me in the wrong direction with troubleshooting initially.

Github Team, I would also upvote the idea to add a clearer error message as to why the branch cannot be merged (perhaps list what merge requirements are failing and some directions on how to rectify the issue. With this particular type of failure perhaps include a link to the 100 commit limit article mentioned by @fgiloux.

That would have saved me a ton of time and headache trying to troubleshoot what was going on.

---

My (Detailed) Fix / How I Got the Commits into master

As for fixing the issue and getting the commits merged into master without loosing my commit history, I ended up splitting up my big branch into smaller 'chunked' branches.

So for example, lets say my branch with the 202 commits on it was called big_branch and it needs to be split into 3 chunk branches (that I can make successive 'chunk' PRs off of to be under the 100 commit limit). I need to create 'chunk' branches starting with the older commits on the branch and working toward the newest ones.

⚠️ IMPORTANT - Be sure to follow these instructions in the order they are given.

Before starting the chunking, I needed to find out what the last commit on master is (Find Latest Master Commit) and then find that commit in the history of big_branch After that, the generic process I used for chunking was as follows:

Phase 1 - Create Chunk Branches

1. Get Commit Hash - get the commit hash of the end of the chunk I want (making sure the number of commits in the chunk will be less than 100)
2. Create New Chunk Branch - create a new branch from big_branch up to the commit hash of the chunk
3. Verify Chunk Branch - change to the new chunk branch and verify its git log history is up to that commit
4. Publish Chunk Branch - publish the new branch on Github

So, first I found what the last commit was on master (my big_branch was branched from this point on master -- so master has no additional commits on it that diverge in history from big_branch). I scrolled through my git log (commit history) of big_branch and found the last commit from master in its history (Find Latest Master Commit) and then went to up to the 76th commit after that and copied its commit hash (let's say the commit hash is 359bd689f9c4abc123d4d1eee39f88e5698d80ed). (Get Commit Hash)

Then while I had big_branch checked out in my terminal, I ran the following to create 'chunk 1' of big_branch and called it big_branch_part1 and have it contain all the commits up & including to the 76th one. (Create New Chunk Branch)

git branch big_branch_part1 359bd689f9c4abc123d4d1eee39f88e5698d80ed

(so the format is git branch <new_chunk_branch_of_big_branch_part_#> <commit_hash_of_##th_commit>)

Then I wanted to verify the new chunk had the commits in it I expected (Verify Chunk Branch). I checked out the 'chunk1' branch using git checkout big_branch_part1 and checked its git log. It had the entire history (including that last commit from master) up to and including the 76th commit after that -- which is showing as the last log entry now. Perfect. I then flipped over to Github Desktop and published the big_branch_part1 to Github (Publish Chunk Branch).
Chunk 1 Creation Complete.

Then I switched back to my terminal and checked out big_branch again and found the 146th commit from the last master commit (so an additional 69 commits after the last commit of chunk 1.) I then copied the commit hash (lets say this one is: ab78cd123c4abc123d4d1sjeuq87e5698d80ec) of this 146th commit and then did:

git branch big_branch_part2 ab78cd123c4abc123d4d1sjeuq87e5698d80ec

I checked out the new big_branch_part2 with git checkout big_branch_part2 and then ran git log to verify that the tip of this branch is the 146th commit. After that I switched over to Github Desktop to publish this branch too.
Chunk 2 Complete.

Rinse and repeat for the 3rd chunk -- back on the terminal, I checked out big_branch again and went to the very last commit (latest / 202nd commit) and copied its hash (let's say its: d7182jshasdkjiq4421dasehs2900ssabcdef. Then ran:

git branch big_branch_part3 d7182jshasdkjiq4421dasehs2900ssabcdef

I then checked out the 3rd chunk with git checkout big_branch_part3 and then ran git log and verified its tip was the 202nd commit. After that I switched over to Github Desktop to publish this branch too.
Chunk 3 Complete.

Phase 2 - Creating and Merging PRs Incrementally
From here the process was as follows:

On Github Website

1. Create a PR for Chunk1 branch
2. Should have a green Rebase and Merge button
3. Do the Rebase and Merge

On Github Desktop App

4. Switch to the master branch and do a Fetch Origin (to get the merged commits from chunk1 on local master now)
5. Switch to Chunk2 branch
6. Do a Fetch Origin for Chunk2 branch to make sure everything is in sync
7. Go to Branch -> Rebase Current Branch... menu option
8. Proceed with the rebase of Chunk2 from master
9. Push the changes to Chunk2 branch up to Github

Back to Github Website

10. Create a PR for Chunk2 (it should now only have 69 commits associated with it and Rebase and Merge should be green)
11. Proceed with Rebase and Merge of Chunk2 PR.

Github Desktop App

12. Switch to the master branch and do a Fetch Origin (to get the merged commits from chunk2 on local master now)
13. Switch to Chunk3 branch
14. Do a Fetch Origin for Chunk3 branch to make sure everything is in sync
15. Go to Branch -> Rebase Current Branch... menu option
16. Proceed with the rebase of Chunk3 from master
17. Push the changes to Chunk3 branch up to Github

Back to Github Website

18. Create a PR for Chunk3 (it should now only have 56 commits associated with it and Rebase and Merge should be green)
19. Proceed with Rebase and Merge of Chunk3 PR.
20. Rejoice for all your commits are now on master from big_branch
21. Close out the original PR for big_branch (if you made one and if it didn't autoclose after the merge of Chunk3)

So, After performing the stuff in Phase 1, I proceeded into Phase 2. I went onto the Github Website and then created a PR for big_branch_part1 (Step1). Since I'm under the 100 commit limit now with chunk 1, I was able to get a green Rebase and Merge button at the bottom of the PR (Step2) and I went ahead and merged it successfully. (Step3)

Now back on Github desktop, I switched over to master branch and did a Fetch Origin to refresh the changes that were merged (Step4). Then I switched over to big_branch_part2 branch (Step5). I did a Fetch Origin for this branch just to make sure everything was in sync with Github (Step6). Then I went to the Branch menu and selected Rebase Current Branch... (Step7) and rebased big_branch_part2 from master (Step8). I then did the force push as prompted to update big_branch_part2 on Github. (Step9)

Now after rebasing big_branch_part2 it only contains 69 commits! I then flipped back over to the Github website and refreshed the page and then created a PR for big_branch_part2 (Step10) and now since it only has 69 commits, I got a green Rebase and Merge button. I proceeded with the Rebase and Merge and it succeeded (Step11).

Back on Github Desktop, I switched back to master and then did a Fetch origin so it picks up the new commits just added to it (Step12). Then I switched over to big_branch_part3 (Step13). I did a Fetch Origin for this branch just to make sure everything was in sync with Github (Step14). Next I went to the Branch menu and selected Rebase Current Branch... (Step15) and rebased big_branch_part3 from master(Step16). I then did the force push as prompted to update big_branch_part3 on Github (Step17).

Now after rebasing big_branch_part3 it only contains 56 commits! So, back to Github website, refresh page, created PR for big_branch_part3 (Step18) and now since it only has 56 commits, I got a green Rebase and Merge button. I then proceeded with the Rebase and Merge (Step19) and it was successful.

This method successfully merged all the 202 commits from big_branch into master all the while maintaining the commit history. Yay! 😄 (Step20)

My original PR for the 202 commits also got auto-closed after this (if I recall correctly) (Step21).

---

For the visually oriented among us, here is an illustration of how I chunked it (it doesn't include the process / order for doing the PRs and rebases though)

---

In hindsight, I suppose instead of creating all 3 chunks to start then having to rebase them from master, I could have just created the first chunk, made a PR and merged it, then rebased big_branch then created up the next chunk branch, made a PR, merged it, rebased big_branch again. At this point I'm guessing that, big_branch PR's Rebase and Merge may go green at this point, otherwise, I could create the next / final chunk big_branch_part3 (essentially a copy of big_branch at this point) and create a PR for that and it should go green to merge. Then I can just close out the original dysfunctional PR for big_branch (or it may autoclose itself since it sees that all of its commits are in master now)

Whew, long post but I hope its helpful for someone else in the future for rectifying this issue.

[vtjballeng]

This remains a substantial frustration for us. All looks good in GitHub Desktop and git locally but can't be rebased on github.com.

In this example 8 commits, so well under 100:

[vtjballeng]

The apparent AI Slop answer from Claude:

I'll help you investigate why the GitHub PR shows rebase conflicts while your local machine shows it's up to date. Let me first examine the pull request details to understand the situation better.I can see the issue! Looking at the pull request data, there's a key piece of information that explains the discrepancy:

The PR shows "rebaseable": false while "mergeable": true and "mergeable_state": "clean".

This indicates that while the branches can be merged cleanly (no merge conflicts), GitHub has determined that the branch cannot be rebased. Let me get more detailed information about the commits and branch state to understand why this is happening.Based on the pull request information and repository data I've gathered, I can help explain the discrepancy between GitHub's rebase indication and what you're seeing locally. Here are the likely reasons for this issue:

GitHub PR Status vs Local Git Status Discrepancy
Key observations from the PR:

GitHub shows: "rebaseable": false
Your local experience: Git/GitHub Desktop shows the branch is up to date with main
Most likely causes:

1. Merge Commit Present in Branch History
The PR contains a merge commit (commit #) titled "Merge branch 'main' into v1.xx.0.x". This indicates that instead of rebasing, the branch was updated by merging main into it. GitHub considers branches with merge commits as "non-rebaseable" because:

A rebase would rewrite the merge commit history
The linear history expected by rebase is broken by the merge

2. GitHub's Rebase Safety Check
GitHub's rebase feature is more conservative than local git operations. It may refuse to rebase when:

There are merge commits in the branch history
Complex conflict resolution might be needed
The branch has been force-pushed previously

3. Branch Protection Rules or Repository Settings
Some repositories have settings that disable certain rebase operations through the GitHub UI for safety reasons.

Solutions:
Option 1: Use Local Rebase (Recommended)
Since your local git shows no conflicts:

bash
git checkout v1.xx.0.x
git rebase main
git push --force-with-lease origin v1.xx.0.x

Option 2: Create a Fresh Branch

bash
git checkout main
git pull
git checkout -b v1.xx.0.x-rebased
git cherry-pick <commit-range-from-original-branch>

Option 3: Accept the Current State
Since the branch is functionally up-to-date (as evidenced by your local tools), you could proceed with the merge as-is. The merge commit doesn't affect functionality, only history linearity.

The discrepancy exists because GitHub's web interface is more restrictive about rebasing when merge commits are present, while local git tools focus on whether there are actual conflicts to resolve.