Forçar envio Git: Como funciona e como usar com segurança

Você provavelmente já passou por isso como desenvolvedor: Você acabou de perceber que seu código tinha um problema no seu último commit. Para desfazer esse erro, você executa alguns comandos e reescreve seu histórico local. Quando você executa git push --force para limpar tudo, seus colegas de equipe avisam que alguns commits estão faltando ou que seu pipeline tem compilações quebradas.

Neste artigo, vou te mostrar o que o git push --force realmente faz, quando usá-lo e como evitar erros. Se você está começando com o Git, recomendo fazer o nosso curso Introdução ao Git ( ) para aprender sobre controle de versão. Além disso, acho que o Git Cheat Sheet, que você pode baixar, é uma referência útil porque tem todas as terminologias e comandos mais comuns do Git.

Quando você pode achar que precisa do git push --force

Digamos que você está limpando seu histórico de commits locais antes de enviar seu trabalho. Para arrumar seu histórico de commits antes de fazer a fusão, você usa o comando git rebase -i main. Tudo parece perfeito localmente, então você tenta atualizar sua ramificação remota comcom um simples git push. Mas, em vez da mensagem de sucesso de sempre, o Git mostra um erro.

Você pode se deparar com outra situação em que, sem querer, você grava dados confidenciais , talvez uma chave API ou senha, e os envia para o servidor remoto. Depois de reescrever a história localmente pra tirar o commit problemático, você percebe que um push normal não atualiza o repositório remoto e os dados confidenciais continuam lá. Em vez disso, aparece uma mensagem de erro.

! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.,
hint: 'git pull ...') before pushing again.

Esse erro de “não avançar rapidamente” é a rede de segurança do Git, que é um aviso de que algo no seu histórico não bate com o que está no servidor. Neste ponto, é tentador executar “ git push --force ” para ignorar esse erro.

Isso pode funcionar bem se você for o único trabalhando no ramo. Mas, projetos compartilhados podem facilmente causar confusão ou apagar o trabalho de outra pessoa.

O que git push --force realmente faz

Normalmente, o Git só deixa você enviar suas alterações se o seu branch local tiver tudo que já está no remoto, incluindo seus novos commits. Mas, às vezes, você pode querer reescrever seu histórico de commits usando git rebase, squashing ou removendodados confidenciais. Quando você fizer isso, sua ramificação local será diferente da ramificação remota. Então, quando você tenta enviar um novo commit, o Git mostra o erro, que protege o branch remoto contra perda de trabalho.

Usar “ git push --force ” diz ao Git para pular a verificação de segurança e substituir o branch remoto pelo que está no seu branch local. 

É assim que fica:

git push --force origin main

Isso vai atualizar o branch principal do remoto pra ficar igual ao seu branch principal local e apagar todos os commits que não estão no seu branch local. 

Agora, imagine seu branch Git como um capítulo de um livro compartilhado que sua equipe está escrevendo em conjunto. Um push padrão é como adicionar novos parágrafos no final do capítulo. Mas, um “ git push --force ” é mais forte e tira o capítulo atual e substitui tudo pela sua versão. 

O risco de usar git push --force é que os colaboradores podem perder o trabalho se basearem as alterações nos commits que você acabou de apagar. Na próxima seção, vamos ver as precauções que você precisa tomar ao usar o comando --force.

Por que isso pode acabar com a sua equipe

Se você forçar as alterações para um branch compartilhado como main ou develop, provavelmente vai acontecer o seguinte:

• Outras filiais locais ficam fora de sincronia: Se seus colegas de equipe fizeram pull dos commits antigos que você apagou do remoto, os históricos locais deles não vão mais combinar com o servidor. As ramificações vão referenciar commits que “desapareceram”, criando confusão e 
• Puxar dá confusão nas fusões ou erros: Quando alguém tentas para git pull depois que você fez um force-push, o Git não vai saber como conciliar o histórico reescrito com a sequência local de commits . Isso muitas vezes leva a commits de mesclagem estranhos, erros enigmáticos ou situações em que os colegas de equipe são instruídos a intervir manualmente com git fetch, git reset ou até mesmo clonar novamente o branch.
• Os pipelines de CI/CD podem falhar: Os pipelines geralmente dependem de hashes de commit consistentes e histórico linear. Uma força push pode fazer com que eles falhem nos testes, reimplantem código incorreto ou travem ao reconstruir em commits desatualizados.

Dá uma olhada no nosso curso CI/CD para Machine Learning pra entender como criar fluxos de trabalho de CI/CD. Também recomendo fazer nosso curso Introdução ao controle de versão de dados com DVC pra aprender a diferença entre controle de versão de dados e controle de versão de código.

Deixa eu te mostrar como é: Você está na ramificação “ feature ” com um colega de equipe. Limpa o histórico local do e, em seguida, executa git push --force. Poucos minutos depois, seu colega de equipe envia as alterações dele. Eles acham que tem erros no Git. Quando eles fazem o pull, eles têm conflitos de mesclagem e um histórico de commits todo bagunçado. Enquanto isso, seu pipeline de CI falha por causa de commits que não foram feitos. Agora, seu colega de equipe perde tempo tentando desembaraçar o galho, e a implantação fica atrasada.

Um toque forte aciona tudo isso.

A opção mais segura: git push --force-with-lease

Pra evitar esses problemas, recomendo usar git push --force-with-lease. Esse comando adiciona uma verificação de segurança ao enviar para um branch remoto, pra evitar commits inesperados.

git push --force-with-lease origin main

Pense em “ --force-with-lease ” como “perguntar se a costa está livre antes de pular”. Antes de fazer qualquer coisa, ele verifica se ninguém mais alterou o branch. Se tudo tá como você viu da última vez, seu histórico tá atualizado. Mas, se tiverem novas alterações que você não conhece, o Git vai te parar e pedir pra você dar uma olhada na situação primeiro. Assim, esse comando vai sempre proteger os colaboradores de sobrescreverem algo sem querer.

Como se recuperar de um Force Push errado

Se você perder alguns commits, não se preocupe, porque ainda dá pra recuperar. O Git sempre guarda um registro das mudanças no commit atual, incluindo reescritas, e guarda isso no reflog.

Veja como você pode recuperar commits perdidos:

Passo 1: Use git reflog pra achar commits perdidos

Execute git reflog para ver o histórico do seu branch.

git reflog

Você pode ver seus commits assim:

abc1234 HEAD@{1}: push: force push
def5678 HEAD@{2}: commit: add new feature

Passo 2: Restaurar o commit perdido

Depois de identificar o hash do commit que você quer recuperar, use o comando abaixo para chegar ao branch específico.

git checkout def5678

Passo 3: Criar um novo ramo

Para recuperar os arquivos com segurança, crie um novo branch git.

git checkout -b recovery-branch

Passo 4: Restaurar o ramo remoto

Agora, manda os commits recuperados pro branch:

git push origin recovery-branch

Lembre-se de que os dados reflog só ficam nas máquinas locais. Então, você não vai conseguir recuperar os commits perdidos se nenhum dos seus colegas de equipe tiver guardado eles no ambiente local.

Recomendo fazer nosso curso Git Intermediário pra saber mais sobre colaboração e como trabalhar com branches no Git.

Melhores práticas para usar git push --force com segurança

Para diminuir a chance de quebrar as coisas, aqui vão alguns bons hábitos para seguir:

• Prefira --force-with-lease em vez de --force:  Esse método é uma opção mais segura que verifica se o branch remoto não mudou desde a última vez que você fez o fetch. Vou ajudar a proteger seus colegas de equipe contra sobrescritas acidentais.

• Evite forçar o envio para ramificações compartilhadas: Nunca force o envio para branches compartilhados como main, master, develop ou release. Só force push para os seus branches de recursos onde você é o único colaborador, pra evitar interrupções.

• Avise sua equipe antes de fazer o force push: Se você precisar fazer um force push para um branch compartilhado, avise sua equipe. Isso vai permitir que eles salvem o trabalho e não percam nada.

• Use ramificações protegidas: Você também pode ativar a proteção para suas ramificações ao usar plataformas como GitHub, GitLab e Bitbucket. Isso evita que você edite diretamente e impede que você acidentalmente envie alterações para ramificações importantes.

Se você quiser saber mais sobre como gerenciar repositórios privados, dê uma olhada nonosso curso Introdução aos conceitos do GitHubpara entender como revisar pull requests ao colaborar no GitHub.

Conclusão

git push --force oferece um jeito legal de reescrever o histórico do seu repositório, seja pra limpar commits ou tirar dados confidenciais. Tenha sempre cuidado ao usar esse comando pra não atrapalhar o fluxo de trabalho da sua equipe.

Sempre que possível, use --force-with-lease em vez disso. Dá a você mais controle sem colocar em risco o trabalho de outras pessoas. Com um pouco de cuidado e comunicação, você pode manter seu histórico Git limpo sem causar problemas para sua equipe.

Recomendo que você dê uma olhada nos nossos programas Git Fundamentals e GitHub Foundations para se tornar um especialista em tudo que é relacionado ao Git.