How to Fix "fatal: refusing to merge unrelated histories" in Git

You run git pull or git merge and Git stops you cold with a fatal error instead of merging. This happens when Git can't find a common commit ancestor between the two histories you're trying to combine, and it's especially common right after initializing a new local repo and connecting it to an existing remote.

The Problem

You clone or initialize a repository, add a remote, and try to pull or merge — and Git refuses:

$ git pull origin main
fatal: refusing to merge unrelated histories

Or, depending on the operation, you might see it during a manual merge:

$ git merge origin/main
fatal: refusing to merge unrelated histories

Sometimes it shows up wrapped in a longer pull output:

From github.com:youruser/yourrepo
 * branch            main       -> FETCH_HEAD
fatal: refusing to merge unrelated histories

Why It Happens

Git tracks history as a chain of commits, and a merge normally needs a common ancestor commit to compute a three-way diff. This error appears when Git detects that the two branches you're merging simply don't share one. The most frequent causes are:

• You ran git init locally and created an initial commit, then added a remote that already has its own separate initial commit (common when a GitHub repo was created with a README and you also committed locally before connecting them).
• You're merging two repositories that were developed independently and never shared a common starting point.
• History was rewritten or squashed on one side (for example, after a git filter-branch cleanup or a repository migration), severing the ancestry link Git relies on.
• You cloned a repo, deleted the .git folder, ran git init again, and re-added the remote — this generates a brand-new root commit unrelated to the old one.

Git added this restriction as a safety check starting with Git 2.9, since blindly merging unrelated projects used to produce confusing, hard-to-untangle history.

The Fix

If you genuinely want to combine the two histories (this is the standard fix for the "new local repo + existing remote" scenario), pass the explicit flag:

git pull origin main --allow-unrelated-histories

Or, if you're doing a manual merge instead of a pull:

git fetch origin
git merge origin/main --allow-unrelated-histories

Git will then attempt a normal three-way merge treating the two root commits as if they had no shared base. You'll likely need to resolve conflicts if both sides created files with the same name (a README.md conflict is extremely common in this exact scenario):

Auto-merging README.md
CONFLICT (add/add): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

Resolve conflicts as you normally would, then finish the merge:

git add .
git commit -m "Merge unrelated histories"
git push origin main

If you're on an older Git client that doesn't recognize the flag, upgrade first — --allow-unrelated-histories requires Git 2.9 or newer:

git --version

Still Not Working?

If the merge succeeds but you end up with duplicate files or a messy history, and what you actually wanted was to discard your local history entirely and just adopt the remote's version, don't merge at all — reset your local branch to match the remote instead:

git fetch origin
git reset --hard origin/main

This throws away your local commits (make sure anything valuable is backed up first), which is often the cleaner option when the "unrelated" local history was just scaffolding you don't need to preserve.

Another scenario worth calling out: you might hit this error after switching your default branch name (from master to main, for example) on a fresh repository while the remote was set up with the opposite convention and an initial commit already in place. In that case, check which branch names actually exist before merging blindly:

git branch -a
git ls-remote --heads origin

If the branch names don't match, rename your local branch to line up with the remote's expectation, or push under the correct name explicitly, rather than forcing an unrelated-histories merge across two branches that were never meant to converge in the first place:

git branch -m master main
git push -u origin main

It's worth being deliberate before reaching for --allow-unrelated-histories as a reflex fix. If the two histories really are unrelated — say, you accidentally pointed a brand-new project at someone else's unrelated repository — merging them just creates a confusing, permanently tangled log. Double-check the remote URL first:

git remote -v

If it's pointing at the wrong repository entirely, fix the remote instead of forcing a merge that was never meant to happen.