Configurei um repositório "principal" remoto e não clonado e o clonei no meu computador. Fiz algumas alterações locais, atualizei meu repositório local e enviei as alterações de volta ao repositório remoto. As coisas estavam bem até esse ponto.

Agora, tive que mudar alguma coisa no repositório remoto. Então mudei algo no meu repositório local. Percebi que a alteração no repositório remoto não era necessária. Então, tentei git pushdo meu repositório local para o meu repositório remoto, mas recebi um erro como:

Para impedir que você perca o histórico, as atualizações de avanço rápido não foram rejeitadas Mesclar as alterações remotas antes de enviar novamente. Consulte a seção "Observação sobre avanço rápido" git push --helppara obter detalhes.

Eu pensei que provavelmente um

git push --force

forçaria minha cópia local a enviar alterações para a remota e torná-la a mesma. Força a atualização , mas quando eu volto ao repositório remoto e faço uma confirmação, percebo que os arquivos contêm alterações desatualizadas (que o repositório remoto principal tinha anteriormente).

Como mencionei nos comentários a uma das respostas :

[I] tentei forçar, mas, ao voltar ao servidor mestre para salvar as alterações, fico com a preparação desatualizada. Assim, quando eu comprometo os repositórios não são os mesmos. E quando tento usar o git push novamente, recebo o mesmo erro.

Como posso corrigir esse problema?

Apenas faça:

git push origin <your_branch_name> --force

ou se você tiver um repositório específico:

git push https://git.... --force

Isso excluirá o (s) seu (s) commit (s) anterior (es) e enviará o seu atual.

Pode não ser adequado, mas se alguém deparar com esta página, pensou que poderia querer uma solução simples ...

Bandeira curta

Observe também que -fé abreviação de --force, então

git push origin <your_branch_name> -f

também irá funcionar.

E se push --forcenão funcionar, você pode fazer push --delete. Olhe para 2 ^nd linha nesta instância:

git reset --hard HEAD~3  # reset current branch to 3 commits ago
git push origin master --delete  # do a very very bad bad thing
git push origin master  # regular push

Mas cuidado...

Nunca mais volte para uma história pública de git!

Em outras palavras:

• Nunca forceforce um repositório público.
• Não faça isso ou qualquer coisa que possa quebrar a de alguém pull.
• Nunca resetou a rewritehistória em um repo alguém já pode ter puxado.

É claro que existem exceções excepcionalmente raras até mesmo para essa regra, mas na maioria dos casos não é necessário fazer isso e isso gerará problemas para todos os outros.

Faça uma reversão.

E sempre tenha cuidado com o que você envia a um repositório público . Revertendo:

git revert -n HEAD~3..HEAD  # prepare a new commit reverting last 3 commits
git commit -m "sorry - revert last 3 commits because I was not careful"
git push origin master  # regular push

Com efeito, os dois HEADs de origem (da reversão e da reinicialização incorreta ) conterão os mesmos arquivos.

edite para adicionar informações atualizadas e mais argumentos push --force

Considere empurrar força com concessão em vez de empurrar, mas ainda prefere reverter

Outro problema push --forcepode trazer é quando alguém pressiona alguma coisa antes de você, mas depois que você já buscou. Se você pressionar forçar sua versão rebaseada agora, substituirá o trabalho de outras pessoas .

git push --force-with-leaseintroduzido no git 1.8.5 ( graças ao comentário do @VonC sobre a pergunta) tenta resolver esse problema específico. Basicamente, ele trará um erro e não será enviado se o controle remoto tiver sido modificado desde a última busca.

Isso é bom se você realmente tem certeza de que push --forceé necessário, mas ainda deseja evitar mais problemas. Eu diria que deveria ser o push --forcecomportamento padrão . Mas ainda está longe de ser uma desculpa para forçar a push. As pessoas que buscaram antes da sua recuperação ainda terão muitos problemas, que poderiam ser facilmente evitados se você revertesse .

E já que estamos falando de git --pushinstâncias ...

Por que alguém iria querer forçar a pressão?

O @linquize trouxe um bom exemplo de força de pressão nos comentários: dados confidenciais . Você vazou erroneamente dados que não devem ser enviados. Se você for rápido o suficiente, poderá "consertá-* lo " forçando um empurrão no topo.

*Os dados ainda estarão no controle remoto, a menos que você também faça uma coleta de lixo ou limpe-a de alguma forma . Há também o potencial óbvio de que ele seja espalhado por outras pessoas que já o buscaram , mas você entendeu.

Primeiro de tudo, eu não faria nenhuma alteração diretamente no repositório "principal". Se você realmente deseja ter um repositório "principal", deve empurrá-lo apenas, nunca alterá-lo diretamente.

Com relação ao erro que você está recebendo, você tentou git pullno repositório local e depois git pushno repositório principal? O que você está fazendo no momento (se eu entendi bem) é forçar o empurrão e depois perder as alterações no repositório "principal". Você deve mesclar as alterações localmente primeiro.

Se eu estiver no meu ramo local A e desejar forçar o envio do ramo local B para o IC do ramo de origem, use a seguinte sintaxe:

git push --force origin B:C

use este comando a seguir:

git push -f origin master

Eu realmente recomendo:

• enviar apenas para o repositório principal

• verifique se o repositório principal é um repositório simples , para nunca ter nenhum problema com a árvore de trabalho do repositório principal não estar sincronizada com sua .gitbase. Consulte " Como enviar um repositório git local para outro computador? "

• Se você precisar fazer uma modificação no repositório principal (vazio), clone-o (no servidor principal), faça sua modificação e retorne a ele

Em outras palavras, mantenha um repositório simples acessível a partir do servidor principal e do computador local, a fim de ter um único repositório upstream do / para o qual extrair / extrair.

Esta foi a nossa solução para substituir o mestre em um repositório corporativo do gitHub, mantendo o histórico.

push -fdominar repositórios corporativos geralmente é desativado para manter o histórico da filial. Esta solução funcionou para nós.

git fetch desiredOrigin
git checkout -b master desiredOrigin/master // get origin master

git checkout currentBranch  // move to target branch
git merge -s ours master  // merge using ours over master
// vim will open for the commit message
git checkout master  // move to master
git merge currentBranch  // merge resolved changes into master

empurre sua filial desiredOrigine crie um PR

Eu tinha a mesma pergunta, mas finalmente entendi. O que você provavelmente precisa fazer é executar os dois comandos git a seguir (substituindo o hash pelo número de revisão de confirmação git):

git checkout <hash>
git push -f HEAD:master