Fix Git 'fatal: refusing to merge unrelated histories'

Cause #1: You're merging two branches that started from different commits

This is the most common scenario. You cloned a repo, made a few commits, then someone else pushed completely different history to the same remote. Or you created a local repo with git init and then tried to git pull from a remote that already had commits. Git sees zero shared history — two completely separate timelines.

The fix: Use --allow-unrelated-histories to force the merge. It tells Git, "I know these histories don't share a parent; merge anyway."

git pull origin main --allow-unrelated-histories

Or if you're merging a branch directly:

git merge other-branch --allow-unrelated-histories

After this, you'll likely get merge conflicts. That's expected. Resolve them normally, commit, and you're done.

Why you'd do this: Sometimes you actually want to merge unrelated histories — like when you're combining two projects into one monorepo, or you previously git checkout --orphan'd a branch to start fresh. Don't use this flag every day. It's a deliberate override.

Cause #2: You accidentally added a remote that points to a different repo

You thought you were adding the correct remote, but it points to a different repo entirely. Maybe you copied the URL wrong, or the upstream renamed their repo. When you try to git pull, Git sees zero common ancestry and spits out the error.

The fix: First, check your remotes:

git remote -v

Compare the URL to what you expect. Wrong? Remove and re-add it.

git remote remove origin
git remote add origin https://github.com/your-org/your-repo.git

Then do a standard pull. No need for --allow-unrelated-histories because the remote now has the correct history. If you already pulled with the wrong remote and merged, you've polluted your local history. In that case, reset to before the merge:

git reflog  # find the commit before the merge
git reset --hard HEAD@{2}  # adjust the number based on your reflog

Pro tip: Use git fetch origin before merging to see what you're pulling. Catch mismatches early.

Cause #3: You tried to push to a remote that already has commits — and you haven't pulled first

This one's subtler. You cloned an empty remote, made local commits, but someone else pushed to that remote after you cloned. Your local history diverges from the remote's history. Git refuses to merge because, technically, your local repo's history and the remote's history originate from different points (the remote's initial commit is unrelated to your local one).

The fix: Pull first, then push. But because the histories are unrelated, you need --allow-unrelated-histories on the pull:

git pull origin main --allow-unrelated-histories

Resolve conflicts, commit, then push normally:

git push origin main

Alternative: If you're certain your local version should overwrite the remote entirely, you can force push — but that's risky. Only do this if you own the repo and don't care about the remote's history:

git push origin main --force

But I'd avoid force pushes unless you absolutely have to. They lose data and annoy your teammates.

Summary table

Bottom line: The --allow-unrelated-histories flag solves 90% of these cases. The other 10% mean you've got a remote misconfiguration or a workflow problem. Fix the remote, not the merge.