Git refusing to merge unrelated histories on rebase

Question

During git rebase origin/development the following error message is shown from Git:

fatal: refusing to merge unrelated histories
Error redoing m         


        

Answer 1

I struggled with this as well, but I managed to find a workaround.

When you run into the error above, just cherry-pick the merge commit and then continue the rebase:

git cherry-pick -m 1 1234deadbeef1234deadbeef
git rebase --continue

Answer 2

Try git pull --rebase development

Answer 3

Two possibilities when this can happen -

1. You have cloned a project and, somehow, the .git directory got deleted or corrupted. This leads Git to be unaware of your local history and will, therefore, cause it to throw this error when you try to push to or pull from the remote repository.

2. You have created a new repository, added a few commits to it, and now you are trying to pull from a remote repository that already has some commits of its own. Git will also throw the error in this case, since it has no idea how the two projects are related.

SOLUTION

git pull origin master --allow-unrelated-histories

Ref - https://www.educative.io/edpresso/the-fatal-refusing-to-merge-unrelated-histories-git-error

Answer 4

I just did a

  git pull --allow-unrelated-histories

Answer 5

git pull origin <branch> --allow-unrelated-histories

You will be routed to a Vim edit window:

• Insert commit message
• Then press Esc (to exit "Insert" mode), then : (colon), then x (small "x") and finally hit Enter to get out of Vim
• git push --set-upstream origin <branch>

Answer 6

I am using the rebase for years and I had never encountered such a problem. However, your first problem is, that you try to do it directly on the remote branch development from the remote repository, called origin. That is literally wrong because rebase is a dangerous command, that restructures the git history. Having said that, you should first try on your local repository and pushing it only, if it works for you as expected.

So, my usual rebase workflow looks like following (but please keep in mind, that you should not use rebase on branches, which you are not the only one committee. For such branches, use simply merge and resolve conflicts, if applicable):

1. make sure you have a clean working tree (no uncommit changes)
2. checkout to the branch you want to rebase onto (for instance, let's say it's master; as a one-line command): git checkout master && git pull origin master && git checkout development
3. Do the actual rebase: git rebase master
4. If it's done and everything works as expected, push it to your remote. For doing so, you need to force it, because the remote host already has the history in another order, the remote would answer with nothing to push. So, we need to say "my local version of the history is correct, overwrite everything on that remote branch using my local version of the history": git push -f origin development

As I already mentioned, keep in mind, that rebase manipulates the git history, that is usually a bad thing. However, it's possible to do that on branches, where no one else commits to. In order to keep the branch pull-able for the other developers, use another merge strategy like merge itself, squash or cherrypick. So, in other words: Rebase shouldn't be your tool on distributed development. It works fine for you if you are the only one who works on this repository.

We use the feature branch strategy. In this, I usually use rebase in order to get the "updates" from the other developers, that happened in the meantime on the master branch. Doing so, it reduces the size of commits that are visible in a pull request. Therefore, it makes it easier for the code reviewer to see my changes made in this feature branch.