How to Fix ‘fatal: refusing to merge unrelated histories’ in Git

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “Is –allow-unrelated-histories dangerous?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “It can create confusing history but isn’t destructive — you can always undo a merge. The bigger risk is using it when you shouldn’t (when repos SHOULD be related and something went wrong). Understand why they’re unrelated before using the flag.”
}
},
{
“@type”: “Question”,
“name”: “What’s the difference between –allow-unrelated-histories and –force?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “–allow-unrelated-histories merges the two histories (both remain in git log). –force overwrites one history with the other (the overwritten commits disappear from the remote).”
}
},
{
“@type”: “Question”,
“name”: “How do I configure git to always allow unrelated histories?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Don’t — the default refusal exists for good reason. Address the root cause instead. If you’re regularly combining repos, use git submodules or a monorepo tool like Turborepo.”
}
},
{
“@type”: “Question”,
“name”: “Can I undo an accidental –allow-unrelated-histories merge?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Yes: git revert -m 1 MERGE_COMMIT_HASH to revert the merge, or git reset –hard HEAD~1 if you haven’t pushed yet.”
}
},
{
“@type”: “Question”,
“name”: “This happened on a team repository — how do I fix it without breaking others?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Don’t force push shared branches. Use git merge origin/main –allow-unrelated-histories to create a merge commit, resolve conflicts, and push normally. Everyone else can git pull normally.”
}
}
]
}

{
“@context”: “https://schema.org”,
“@type”: “TechArticle”,
“headline”: “How to Fix ‘fatal: refusing to merge unrelated histories’ in Git”,
“description”: “Fix the ‘fatal: refusing to merge unrelated histories’ error with safe solutions — when to use –allow-unrelated-histories and better alternatives.”,
“url”: “”,
“datePublished”: “2026-06-29 16:05:00”,
“dateModified”: “2026-06-29 16:05:00”,
“author”: {
“@type”: “Organization”,
“name”: “TechPulse Editorial Team”,
“url”: “https://techpulsesite.com”
},
“publisher”: {
“@type”: “Organization”,
“name”: “TechPulse”,
“url”: “https://techpulsesite.com”,
“logo”: {
“@type”: “ImageObject”,
“url”: “https://techpulsesite.com/wp-content/uploads/logo.png”
}
}
}

The error “fatal: refusing to merge unrelated histories” appears when you try to merge or pull from a Git repository that has no common ancestor with your current branch. This happens most often when you create a new repo on GitHub with a README and try to push a local project, or when you’re combining two completely separate repositories. Here’s every scenario and its correct fix.

Why This Error Occurs

Git tracks history through a chain of commits. When two repos have never shared a common commit (unrelated histories), Git refuses to merge them by default since Git 2.9 — it assumes you made a mistake. The error looks like:

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

Or when merging:

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

Scenario 1: Created Repo on GitHub with README, Local Already Has Commits

This is the most common cause. You initialized a GitHub repo with a README (or license), then try to push your local project. Your local has commits; GitHub has one commit (the README) — no shared history.

# ✅ Option 1: Force push (destroys the README commit — simplest)
git push -u origin main --force
# WARNING: Only use if nobody else has cloned the repo
# and you don't mind losing the GitHub-created README

# ✅ Option 2: Allow merge (keeps both, creates merge commit)
git pull origin main --allow-unrelated-histories
# Resolve any conflicts (often just README vs your code)
git push origin main

# ✅ Option 3: Rebase (cleanest linear history)
git fetch origin
git rebase origin/main
# Resolve any conflicts
git push origin main

Scenario 2: Combining Two Separate Repositories

You have two repositories and want to merge one into the other (e.g., combining a frontend repo and backend repo into a monorepo).

# Add the second repo as a remote
git remote add other-repo https://github.com/user/other-repo.git
git fetch other-repo

# Merge allowing unrelated histories
git merge other-repo/main --allow-unrelated-histories

# All files from both repos are now in working tree
# Commit the merge
git commit -m "Merge other-repo into monorepo"

To keep the second repo’s files in a subdirectory (cleaner for monorepos):

# Better approach: move the second repo's files to a subdirectory first
git fetch other-repo
git checkout -b temp-branch other-repo/main

# Move all files to a subdirectory
mkdir backend
git ls-files | xargs -I{} git mv {} backend/{}
git commit -m "Move to backend/ subdirectory"

# Merge back into main
git checkout main
git merge temp-branch --allow-unrelated-histories

Scenario 3: git pull After Repo Was Recreated

A team member deleted and recreated the remote repository, wiping its history. Your local copy has commits the new remote doesn’t.

# Check what happened
git log --oneline -5                    # your local history
git log --oneline origin/main -5       # remote history

# If you want to keep your local history (usually correct)
git push origin main --force-with-lease
# --force-with-lease is safer than --force: fails if remote has
# commits you haven't fetched (prevents accidental overwriting)

# If you want the new remote's history (abandon local)
git fetch origin
git reset --hard origin/main

The Right Way: Don’t Create README on GitHub When You Have Local Code

The real fix is prevention. When you have an existing local project:

# 1. Create repo on GitHub WITHOUT initializing (no README, no .gitignore)
# 2. Add remote and push
git init                              # if not already a repo
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/user/repo.git
git push -u origin main               # no conflicts because remote is empty

When Is –allow-unrelated-histories Safe?

# Safe scenarios:
# - Initializing a project that was created with a README on GitHub
# - Combining unrelated repos intentionally into a monorepo
# - Recovering from an accidental repo recreation

# Unsafe scenarios:
# - You don't understand why the histories are unrelated
# - The remote was supposed to be a fork of your local (shouldn't be unrelated)
# - Two branches of the same project (investigate root cause instead)

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

Checking Repository Relationships

# See if two commits share ancestry
git merge-base --is-ancestor commit1 commit2
echo $?  # 0 = ancestor, 1 = not ancestor

# See all commit ancestry graph
git log --oneline --graph --all

# Find common ancestor (if any)
git merge-base branch1 branch2

Frequently Asked Questions

Q: Is –allow-unrelated-histories dangerous?
A: It can create confusing history but isn’t destructive — you can always undo a merge. The bigger risk is using it when you shouldn’t (when repos SHOULD be related and something went wrong). Understand why they’re unrelated before using the flag.

Q: What’s the difference between –allow-unrelated-histories and –force?
A: --allow-unrelated-histories merges the two histories (both remain in git log). --force overwrites one history with the other (the overwritten commits disappear from the remote).

Q: How do I configure git to always allow unrelated histories?
A: Don’t — the default refusal exists for good reason. Address the root cause instead. If you’re regularly combining repos, use git submodules or a monorepo tool like Turborepo.

Q: Can I undo an accidental –allow-unrelated-histories merge?
A: Yes: git revert -m 1 MERGE_COMMIT_HASH to revert the merge, or git reset --hard HEAD~1 if you haven’t pushed yet.

Q: This happened on a team repository — how do I fix it without breaking others?
A: Don’t force push shared branches. Use git merge origin/main --allow-unrelated-histories to create a merge commit, resolve conflicts, and push normally. Everyone else can git pull normally.

Conclusion

The “refusing to merge unrelated histories” error almost always comes from creating a GitHub repo with an initial README before pushing your local project. The cleanest fix: push with --force if nobody else has the remote, or use --allow-unrelated-histories to merge both histories. Best practice going forward: create empty GitHub repos and push local code, rather than initializing repos on GitHub when you already have local commits.