Fix Git's Merge Unrelated Histories Error

"fatal: refusing to merge unrelated histories" shows up the moment you try to pull or merge two Git histories that don't share a common ancestor commit, and it almost always happens for one of three reasons: you re-initialized a repo that used to have a different .git folder, you created a GitHub repo with a README and then tried to push a local project that already had commits, or you're merging two codebases that genuinely started life as separate projects. Git added this as a safety check in version 2.9, and it's doing exactly its job — it just doesn't explain itself well in the error message.

I ran into the "ugly" version of this on a client's Laravel project a few months back. They'd deleted the .git folder to "start clean" after a botched deploy, re-ran git init, and then tried to pull from the GitHub remote that still had eighteen months of commit history. Git refused, the client panicked and asked if they'd lost their history, and the actual fix took about ninety seconds once I explained what was going on.

What "Refusing to Merge Unrelated Histories" Actually Means

Every Git commit points back to its parent, and a repository's "history" is really just that chain of parent pointers going back to the first commit. Two branches have a common history when you can walk back from both of them and land on the same root commit. When you git init a brand-new repository, that new repo gets its own first commit with no parent at all — a completely separate root.

So when you add a remote and try to pull, Git looks at your local root commit and the remote's root commit, sees they don't connect, and assumes you probably don't actually want to merge two unrelated projects together by accident. That's the whole check. It's not corrupting anything or detecting a real conflict — it's a guard rail that showed up in Git 2.9 specifically because people were accidentally merging unrelated repos and ending up with a confusing mess.

Why This Happens in Real Projects

The scenario I hit most often with clients is exactly the one above: someone deletes .git (usually trying to "fix" something unrelated) and re-initializes instead of just fixing whatever was actually broken. The new .git init has no idea the old history ever existed, even though the remote repo on GitHub or GitLab still has it.

The second common case is the opposite direction: you create a new repository on GitHub and tick "Initialize this repository with a README," then try to push an existing local project into it. GitHub's auto-generated README commit and your local project's first commit are both roots, and neither one knows about the other.

A third case, less common but real, is deliberately combining two previously-separate projects — merging a standalone library into a monorepo, for instance. Here the histories are unrelated on purpose, and you genuinely want Git to merge them while keeping both commit histories intact.

The Fix: --allow-unrelated-histories

For the first two cases — the ones that are really just an accident of setup, not an intentional merge of two different projects — the fix is a single flag on whichever command Git just rejected:

# if a pull failed with the error
git pull origin main --allow-unrelated-histories

# if you were merging a branch directly
git merge some-branch --allow-unrelated-histories

# then resolve any real conflicts the usual way
git status
git add .
git commit -m "Merge unrelated histories"

That flag doesn't change what Git actually does during the merge — it just removes the safety check, so Git treats the two root commits as any other merge and walks through the normal three-way merge process. If the file contents genuinely conflict (which happens with the GitHub-README case, since both sides have a README.md), you'll get standard merge-conflict markers to resolve, same as any other merge.

If you're in the "deleted .git by accident" situation specifically, there's a cleaner fix than merging at all, assuming you haven't made any new local commits yet: just delete the fresh .git folder again and re-clone from the remote instead. You lose nothing, because the remote already has everything, and you skip the unrelated-histories dance entirely.

When You Shouldn't Just Slap On the Flag

Most tutorials treat --allow-unrelated-histories as a universal unblock-and-move-on fix, and I think that's the wrong default advice. If you deleted .git by accident and have zero new local commits, re-cloning is faster, cleaner, and leaves you with an identical result — there's no reason to generate an unnecessary merge commit stitching two histories together when one of them is just a throwaway reinitialization.

The flag earns its place in the two situations where the histories genuinely both matter: the GitHub-README case (your project already has real commits you don't want to lose) and actually combining two separate codebases on purpose. In those cases, don't just run the merge and walk away — check git log --graph --oneline --all afterward and make sure the resulting history actually makes sense, especially if you're folding one project into a monorepo where commit order and authorship will matter later for git blame and release notes.

Frequently Asked Questions

Does --allow-unrelated-histories delete any of my commits? No. It only disables the check that blocks the merge from starting — the merge itself still runs normally, keeping every commit from both histories. If you don't like the result, git merge --abort before committing puts you right back where you started.

I ran the merge and now my repo has a weird merge commit with two parents pointing to totally different projects — is that normal? Yes, and it's expected once you've merged two genuinely unrelated histories. A merge commit referencing two unrelated root commits is exactly what "unrelated histories merged" looks like in git log --graph. It's not a bug.

Can I just force-push to skip the merge entirely? You can, with git push --force, but that overwrites the remote's history completely rather than combining it with yours — anyone else's clone of the old remote history becomes instantly out of sync. Only do this if you're certain the remote content is disposable (like the auto-generated README case on a repo nobody else has touched yet).

Does this only happen with GitHub, or is it a plain Git thing? It's plain Git behavior, introduced in Git 2.9, completely independent of GitHub, GitLab, or Bitbucket. Any two repositories with separate root commits trigger it, whether or not a hosting platform is involved.

Conclusion

"Refusing to merge unrelated histories" is Git protecting you from a mistake, not reporting damage. If you deliberately created two root commits and now want one unified history, --allow-unrelated-histories on the pull or merge command is the correct, permanent fix. If the "unrelated" root is just an accidental re-init with nothing of value in it yet, skip the flag entirely and re-clone instead — it's faster and avoids leaving a pointless merge commit in your history forever.