How to Fix Git Error: “refusing to merge unrelated histories”

Quick Fix

Add the --allow-unrelated-histories flag. This tells Git to combine the two histories on purpose, even though it can't find a shared starting commit.

1. If pulling: run git pull origin main --allow-unrelated-histories (replace main with your branch name).
2. If merging a local branch: run git merge branch-name --allow-unrelated-histories.
3. Resolve any conflicts that appear, then git add the resolved files and git commit to finish the merge.

Step-by-Step Guide

What this error means

Git tracks history as a chain of commits, and when you merge two branches, it normally looks for a shared "common ancestor" commit to figure out what changed. This error appears when Git cannot find any common ancestor between the two histories you are trying to combine, so it refuses the merge as a safety measure rather than risk mixing two completely unrelated projects.

This safeguard was introduced in Git 2.9 specifically to stop people from accidentally merging unrelated histories into an existing project. It most commonly shows up in a few situations, detailed below as separate causes since the right fix depends on how you got here.

Cause 1: You ran git init locally instead of git clone

This is the most frequent cause: you did a git init on something like "the same" set of files locally, then tried to merge with the files on the repository, when the better way is to clone from the repository and work from that. This often happens after getting a new computer or starting a new project folder and then linking it to an existing GitHub repo with git remote add origin.

1. Confirm you have the right remote URL. Double check the repository address before doing anything else, since forcing a merge into the wrong repo can cause real damage.
2. Fetch the remote history. Run git fetch origin to pull down the remote's commit history without merging yet.
3. Merge with the flag. Run git merge origin/main --allow-unrelated-histories (or use git pull origin main --allow-unrelated-histories to do fetch and merge in one step).
4. Resolve conflicts if prompted. Open any conflicted files, fix the conflict markers, then run git add <file> followed by git commit.
5. Going forward, prefer cloning. For future setups, use git clone <url> instead of git init + remote add, which avoids this error entirely.

Cause 2: Combining two genuinely separate repositories

Sometimes you are intentionally merging two different projects (for example, folding a backend repo into a frontend repo). Since they never shared history, Git flags this by design.

1. Consider moving files into a subdirectory first. In the repo you're importing, create a folder and move all its files into it before merging, so filenames don't collide with the target repo.
2. Add it as a remote. In your main project run git remote add otherrepo ../path-or-url then git fetch otherrepo.
3. Merge with the flag. Run git merge otherrepo/main --allow-unrelated-histories.
4. Resolve any add/add conflicts. These are common when both repos have files with the same name (like README.md); edit the file to keep what you want, then git add and git commit.

Cause 3: The .git folder was deleted, corrupted, or a new computer/OS reinstall

If your local .git directory is missing or was rebuilt, Git loses its record of the project's real history, since the .git directory is crucial for Git to track the complete history of the project, including commits, branches, tags, and remote repositories, and without it Git cannot recognize your local history.

1. Back up your current files to a separate folder first, just in case.
2. Re-clone the repository fresh. Run git clone <remote-url> into a new folder to get a clean copy with full history intact.
3. Manually copy your uncommitted changes back in from your backup, then commit them normally — this avoids needing --allow-unrelated-histories at all.
4. Only use the merge flag as a last resort if re-cloning isn't practical, following the steps in Cause 1.

Cause 4: Happening during a rebase instead of a merge

The same error can appear during git rebase when the branch being rebased has no shared commits with the target branch, often after a repository split or when working across forks with diverged history.

1. Apply the flag to rebase. Run git rebase <branch-name> --allow-unrelated-histories.
2. Resolve conflicts as they appear. Rebase may stop repeatedly at each conflicting commit; fix conflicts, run git add <file>, then git rebase --continue until it finishes.
3. Abort if it gets messy. Run git rebase --abort to back out completely and reconsider whether a plain merge (Cause 1 or 2) is safer than a rebase here.

Fix 5: Undo it if something went wrong

Forcing unrelated histories together can create a tangled commit graph or unwanted results, especially if you merged the wrong remote.

1. Abort an in-progress merge. Run git merge --abort before committing if conflicts look wrong or unexpected.
2. Reset after a bad commit. If you already committed the merge, run git reset --hard HEAD~1 (only if you haven't pushed yet) to undo it, or restore from a backup/reflog if you have pushed.
3. Check git reflog to find the commit hash from before the merge if you need to recover lost work.

When to get more specific help

1. Sync tools like Obsidian Git. If this happens inside an app that wraps Git (for example Obsidian's Git plugin combined with iCloud sync), the fix is the same underlying command, but you may need the app's terminal/command panel or its official support forum to enter it correctly.
2. Shared team repositories. If you're unsure whether merging unrelated histories will overwrite a teammate's work, coordinate with them first or ask in your team's version control channel rather than forcing the merge alone.
3. Repository looks genuinely corrupted. If re-cloning still fails or your remote history looks wrong, that's a sign to check with the repository host's support (GitHub, GitLab, etc.) rather than continuing to force merges.