How to Fix “Refusing to Merge Unrelated Histories” in Git

Git shows “fatal: refusing to merge unrelated histories” when the branches you are combining do not share a common ancestor. This can happen when a local project and a remote repository were initialized separately. First confirm that you are combining the intended repositories, then use Git’s explicit option to allow the merge.

Why does Git refuse to merge unrelated histories?

A normal merge joins histories that share a common ancestor. When neither branch descends from a commit on the other, Git cannot infer that they belong to the same project and refuses by default. The check helps prevent accidentally combining unrelated repositories.

A frequent cause is creating a project locally with git init, making commits, and separately creating a GitHub repository with its own initial README or license commit. Those histories started independently. The same message can also indicate a wrong remote or branch, so do not add --allow-unrelated-histories until you have checked what Git is being asked to combine.

Before you merge: inspect and protect your work

Confirm the current branch and remote, and make sure your working tree is clean or your changes are safely committed. Then fetch remote updates without merging them:

git status
git branch --show-current
git remote -v
git fetch origin
git log --oneline --graph --decorate --all -20

Replace origin if your remote has a different name. Confirm the remote URL and the branch you plan to merge, such as origin/main. If the local and remote histories should already be connected, a wrong remote or branch may be the real problem; correct that instead of forcing a merge. Consider creating a backup branch before a history-changing operation.

Merge unrelated histories intentionally

Use this option only after confirming that the two independent histories are meant to become one project. Switch to the branch that should receive the other history, then merge the intended remote branch:

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

Replace main with your destination branch and origin/main with the branch you intend to bring in. Git may create a merge commit immediately or pause for conflicts. Review the files and commit contents before pushing the result.

If your goal is to upload a local project to a newly created GitHub repository, the simplest route is usually to create the remote without an initial README, license, or .gitignore. See the guide to uploading a project to GitHub. If the remote already has useful content, merging may be the appropriate choice.

Resolve conflicts during the merge

If Git reports conflicts, check which files need attention:

git status

Open each conflicted file, choose the correct combined content, and remove the conflict markers. Stage each resolved file, then finish the merge:

git add FILE
git merge --continue

Replace FILE with each resolved path. Review the resulting merge commit and run your project’s checks before pushing. To cancel an in-progress merge and return to the state before the merge started, use git merge --abort.

Push the merged history

When the merge is complete and verified, push the destination branch to its remote:

git push origin main

Replace main with the branch you actually merged into. If the push is rejected, fetch and inspect the new remote commits rather than force-pushing over them.

What not to do

• Do not use the unrelated-histories option to silence an error before checking the remote URL and branch.
• Do not reset or force-push to erase one side’s history unless you have confirmed it is disposable and coordinated with anyone who shares the repository.
• Do not ignore conflicts or push without reviewing the merge result. Both independent histories may contain important files.

Frequently asked questions

Is it safe to allow unrelated histories?

It is safe when you have verified that the two histories belong together and reviewed the resulting merge. The option bypasses Git’s default protection against joining histories with no common ancestor; it does not determine whether the repositories are related or resolve conflicts for you.

Can I use the option with git pull?

Git supports git pull --allow-unrelated-histories, but fetching first and inspecting the remote branch before running an explicit merge makes it easier to verify the intended histories. Use the pull form only when you have confirmed the repository, branch, and merge strategy.