Como corrigir ‘fatal: recusando-se a mesclar históricos não relacionados’ no Git

O erro“fatal: recusando-se a mesclar histórias não relacionadas” aparece quando você tenta mesclar ou extrair de um repositório Git que não possui ancestral comum com seu branch atual. Isso acontece com mais frequência quando você cria um novo repositório no GitHub com um README e tenta enviar um projeto local, ou quando você combina dois repositórios completamente separados. Aqui estão todos os cenários e sua correção correta.

Por que esse erro ocorre

O Git rastreia o histórico por meio de uma cadeia de commits. Quando dois repositórios nunca compartilharam um commit comum (históricos não relacionados), o Git se recusa a mesclá-los por padrão desde o Git 2.9 — ele assume que você cometeu um erro. O erro é semelhante a:

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

Ou ao mesclar:

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

Cenário 1: Repo criado no GitHub com README, o local já possui commits

Esta é a causa mais comum. Você inicializou um repositório GitHub com um README (ou licença) e tentou enviar seu projeto local. Seu local possui commits; GitHub tem um commit (o README) — sem histórico compartilhado.

# ✅ 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

Cenário 2: Combinando dois repositórios separados

Você tem dois repositórios e deseja mesclar um com o outro (por exemplo, combinando um repositório de front-end e um repositório de back-end em um 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"

Para manter os arquivos do segundo repositório em um subdiretório (limpador para 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

Cenário 3: git pull após a recriação do repositório

Um membro da equipe excluiu e recriou o repositório remoto, apagando seu histórico. Sua cópia local confirmou, o novo controle remoto não.

# 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

A maneira certa: não crie README no GitHub quando você tiver código local

A verdadeira solução é a prevenção. Quando você tem um projeto local existente:

# 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

Quando –allow-unrelacionado-histories é seguro?

# 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

Verificando relacionamentos de repositório

# 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

Perguntas Frequentes

P: –allow-un Related-historias é perigoso?
R: Isso pode criar um histórico confuso, mas não é destrutivo — você sempre pode desfazer uma mesclagem. O maior risco é usá-lo quando não deveria (quando os repositórios DEVEM estar relacionados e algo deu errado). Entenda por que eles não estão relacionados antes de usar o sinalizador.

P: Qual é a diferença entre –allow-unrelated-histories e –force?
A: --allow-unrelated-histories mescla os dois históricos (ambos permanecem no git log). --force substitui um histórico pelo outro (os commits substituídos desaparecem do controle remoto).

P: Como configuro o git para sempre permitir históricos não relacionados?
R: Não faça isso – a recusa padrão existe por um bom motivo. Em vez disso, resolva a causa raiz. Se você combina repositórios regularmente, use submódulos git ou uma ferramenta monorepo como o Turborepo.

P: Posso desfazer uma mesclagem acidental de –allow-unrelated-histories?
R: Sim:git revert -m 1 MERGE_COMMIT_HASH para reverter a mesclagem ougit reset --hard HEAD~1 se você ainda não empurrou.

P: Isso aconteceu em um repositório de equipe — como faço para corrigir isso sem quebrar outros?
R: Não force o push de ramificações compartilhadas. Usargit merge origin/main --allow-unrelated-histories para criar um commit de mesclagem, resolver conflitos e enviar push normalmente. Todos os outros podemgit pull normalmente.

Conclusão

O erro “recusar mesclar históricos não relacionados” quase sempre vem da criação de um repositório GitHub com um README inicial antes de enviar seu projeto local. A correção mais limpa: push com--force se ninguém mais tiver o controle remoto, ou use--allow-unrelated-histories mesclar os dois históricos. Melhores práticas daqui para frente: crie repositórios GitHub vazios e envie código local, em vez de inicializar repositórios no GitHub quando você já possui commits locais.