Como corrigir erro de avanço não rápido rejeitado pelo git push

O erroAs atualizações foram rejeitadas porque o controle remoto contém trabalho que você não possui localmente (um erro que não é de avanço rápido) significa que alguém enviou commits para o branch remoto que você não possui. O Git bloqueia seu push para evitar a substituição do trabalho. Veja como resolver isso com segurança.

O que esse erro significa

$ git push origin main
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the remote contains work that
hint: you do not have locally. This is usually caused by another
hint: repository pushing to the same ref.

Alguém (ou você de outra máquina) enviou commits para o branch remoto depois que você puxou pela última vez. Sua filial local e a remota divergiram. O Git não permitirá que você faça push porque isso descartaria seus commits.

Correção 1: Puxar e Empurrar (Mesclar)

# Fetch and merge the remote changes into your local branch
git pull origin main

# This creates a merge commit combining their work and yours.
# Resolve any conflicts if they occur, then:
git push origin main

Este é o padrão seguro. Ele integra os commits remotos aos seus por meio de um commit de mesclagem e, em seguida, seu push é bem-sucedido.

Correção 2: Pull com Rebase (histórico mais limpo)

# Replay YOUR commits on top of the remote's - linear history, no merge commit
git pull --rebase origin main

# If conflicts occur during rebase, resolve them, then:
git add 
git rebase --continue

# Then push
git push origin main

O rebase fornece um histórico linear e mais limpo sem um commit de mesclagem. Muitas equipes preferem isso. Seus commits são reproduzidos além do trabalho remoto mais recente.

Correção 3: buscar e revisar primeiro (abordagem cuidadosa)

# See what's on the remote before integrating
git fetch origin

# Compare your branch with the remote
git log HEAD..origin/main    # commits on remote you don't have
git log origin/main..HEAD    # your commits not on remote

# Then choose to merge or rebase
git merge origin/main        # or: git rebase origin/main
git push origin main

Definir uma estratégia pull padrão

# Configure how git pull behaves (avoids the "divergent branches" warning)

# Merge (default) - creates merge commits
git config --global pull.rebase false

# Rebase - linear history
git config --global pull.rebase true

# Fast-forward only - fail if not possible (forces you to decide)
git config --global pull.ff only

Quando você tiver certeza de que deseja sobrescrever (perigoso)

# ⚠️ ONLY if you're certain the remote commits should be discarded
# (e.g., your own feature branch nobody else uses)

# --force-with-lease is safer than --force:
# it fails if the remote changed since your last fetch
git push --force-with-lease origin my-feature-branch

# ❌ NEVER force push to shared branches (main, develop)
# It permanently deletes other people's commits
git push --force origin main   # DON'T do this on shared branches

Aviso: Forçar o push para um branch compartilhado destrói os commits de outras pessoas. Force apenas o push para suas próprias ramificações de recursos nas quais ninguém mais trabalha e prefira--force-with-lease.

Compreendendo a diferença

# Before: your local and remote have diverged
#   A---B---C (your local main)
#        #         D---E (remote main - someone else's commits)

# git pull (merge) creates:
#   A---B---C---F (merge commit)
#        \     /
#         D---E

# git pull --rebase creates (cleaner):
#   A---B---D---E---C' (your C replayed on top)

Perguntas Frequentes

P: Devo mesclar ou rebasear para corrigir isso?
R: Mesclar (git pull) é o padrão seguro e preserva o histórico exato. Rebase (git pull –rebase) fornece um histórico linear mais limpo. Para filiais compartilhadas, funciona; para suas próprias ramificações de recursos antes de um PR, o rebase mantém o histórico organizado. Siga a convenção da sua equipe.

P: Por que não posso simplesmente forçar o push?
R: Forçar o envio para um branch compartilhado exclui permanentemente os commits enviados por outros — você perderia o trabalho deles. Apenas force o push (com –force-with-lease) para suas próprias ramificações de recursos que ninguém mais usa. Nunca force o push principal ou o desenvolvimento.

P: O que –force-with-lease faz e –force não faz?
A: --force-with-lease verifica se o controle remoto não mudou desde sua última busca – se alguém pressionou nesse meio tempo, ele falhará em vez de sobrescrever. É uma rede de segurança que evita a destruição acidental de commits que você não viu. Sempre prefira isso ao invés de –force simples.

P: Tive conflitos de mesclagem após extrair. E agora?
R: Abra os arquivos em conflito, resolva os conflitos (escolha quais alterações manter) e entãogit add os arquivos resolvidos. Para uma mesclagem,git commit. Para uma rebase,git rebase --continue. Então empurre.

P: Como evito esse erro no futuro?
R: Puxe antes de começar a trabalhar e antes de empurrar. Comunique-se com sua equipe sobre quem está trabalhando em quê. Em filiais compartilhadas ativas, faça pull com frequência para se manter atualizado e minimizar a divergência.

Conclusão

A rejeição de push sem avanço rápido significa que o controle remoto tem commits que você não possui localmente – o Git protege esses commits bloqueando seu push. A correção é simples:puxe as alterações remotas primeiro (git pullpara mesclar ougit pull --rebasepara limpar o histórico), resolva quaisquer conflitos e, em seguida, pressione. Nunca force o push para filiais compartilhadas — isso destrói o trabalho dos outros. Se você precisar sobrescrever sua própria ramificação de recursos, use--force-with-lease (mais seguro que--force). Para evitar esse erro, puxe com frequência e comunique-se com sua equipe. Entender que o Git está protegendo commits que você não viu torna a correção intuitiva: integre o trabalho remoto e depois envie.