Updates were rejected because the remote contains work: resolver o push

Esse erro significa que a branch remota contém commits que sua branch local não contém. O Git recusa o push porque mover a referência para sua ponta faria o trabalho remoto deixar de ser alcançável por aquele nome. Busque, compare, integre e tente novamente.

O erro foi reproduzido com dois clones de um bare local. A primeira cópia enviou um livro; a segunda criou outro commit sem buscar antes:

git push

Leia rejected, failed e hint como uma mensagem só

rejected é o resultado para main. failed to push some refs resume a operação. O hint explica a causa provável e sugere integração. Não são três erros diferentes. A parte (fetch first) indica que sua observação do remote está atrasada.

Confirme o destino antes de agir:

git remote -v

O upstream local ainda não sabia que outra cópia havia avançado. Mesmo quando git branch -vv diz que a branch está adiante, a comparação usa o origin/main conhecido antes do fetch. Ela não é consulta ao vivo.

Duas cópias criam a divergência em poucos passos

O remote estava em 8eb0591. A cópia A adicionou Refatoração e enviou 0cac5b3. A cópia B, ainda na base antiga, adicionou DDD e criou 62f6095.

git --no-pager log --oneline --graph --decorate --all -4

O commit de Refatoração ainda não aparece porque B não fez fetch. Esse detalhe é o mecanismo do erro, não uma falha visual.

Fetch revela o commit que faltava

git fetch origin

Agora o grafo tem duas pontas que descendem de 8eb0591. Você precisa decidir se integra com merge, preservando a bifurcação, ou rebase, reaplicando o commit local sobre a ponta remota.

Pull rebase pode pedir resolução

No sandbox, ambos adicionaram uma linha no mesmo lugar. O pull com rebase parou de forma controlada:

git pull --rebase

Rebase não é um botão para evitar conflito. Ele muda a ordem de aplicação; se o contexto disputa a mesma região, você ainda decide o conteúdo. O status e o arquivo mostraram os dois livros.

git status --short
sed -n '1,10p' catalogo.txt

Resolva, continue e faça push normal

Depois de manter os dois livros, o teste preparou e continuou. O commit foi recriado com outro hash, 02e39a2:

git add catalogo.txt
GIT_EDITOR=true git rebase --continue

Agora a história era linear:

git --no-pager log --oneline --graph --decorate -4

O push seguinte avançou normalmente:

git push

Um git pull --no-rebase também poderia integrar, criando merge se necessário. A escolha depende da política do time; o requisito é preservar ambos os trabalhos e revisar a resolução.

Com merge, a sequência segura é git fetch origin, revisar o grafo e executar git merge origin/main. O commit local mantém o mesmo hash e, havendo divergência, nasce um commit com dois pais. Com rebase, seus commits locais são recriados sobre origin/main, por isso os hashes mudam. O código final pode ser igual nos dois caminhos, mas o histórico não é. Escolha pelo contrato do projeto, não pela tentativa de produzir uma linha “bonita” a qualquer custo.

Se a working tree não está limpa, pare antes do pull. Faça um commit coerente na branch certa ou use stash temporário. Misturar alterações não relacionadas com a resolução aumenta a superfície do conflito e dificulta provar o que veio do remote.

Force with lease é exceção consciente

--force manda o servidor aceitar sua referência, mesmo que você não tenha visto a ponta atual. --force-with-lease exige que a referência remota ainda esteja no valor esperado e recusa se alguém avançou desde seu último fetch. Ele é apropriado quando uma branch de tarefa foi rebaseada intencionalmente e o time permite reescrita. Não use na main protegida.

O caso do repositório criado com README no GitHub pode produzir esse erro ou um histórico sem raiz comum, dependendo do estado. A prevenção é criar remoto vazio quando o commit inicial já existe localmente, como ensina subir projeto.

Sua missão é reproduzir com bare e dois clones, anotar as três pontas antes e depois do fetch e resolver sem force. Depois leia rebase e o fluxo de equipe para decidir qual histórico o projeto aceita.