Como faço para empurrar o commit alterado para o repository Git remoto?

Quando eu trabalhei um pouco com o meu código fonte, eu fiz o meu commit usual e empurrei para um repository remoto. Mas então notei que esqueci de organizar minhas importações no código-fonte. Então eu faço o comando emendar para replace o commit anterior:

> git commit --amend 

Infelizmente, o commit não pode ser enviado de volta ao repository. É rejeitado assim:

 > git push origin To //my.remote.repo.com/stuff.git/ ! [rejected] master -> master (non-fast forward) error: failed to push some refs to '//my.remote.repo.com/stuff.git/' 

O que devo fazer? (Eu posso acessar o repository remoto.)

Na verdade, eu já empurrei com o repository --force e .git e fui repreendido pelo Linus BIG TIME . Em geral, isso criará muitos problemas para outras pessoas. Uma resposta simples é “não faça isso”.

Eu vejo outros dando a receita para fazer isso de qualquer maneira, então eu não vou repeti-los aqui. Mas aqui está uma dica para se recuperar da situação depois que você retirou o commit alterado com –force (ou + master).

  1. Encontre o commit antigo que você alterou (chame de old e chamaremos o novo commit que você criou alterando o new ).
  2. Crie uma mesclagem entre o old e o new , gravando a tree do new , como git checkout new && git merge -s ours old .
  3. Mesclar isso ao seu mestre com git merge master
  4. Atualize seu mestre com o resultado com o git push . HEAD:master git push . HEAD:master
  5. Empurre o resultado.

Então, as pessoas que tiveram a infelicidade de basear seu trabalho no compromisso que você anulou ao emendar e forçar um empurrão (que é o fato de você estar sendo um menino muito ruim ) verão que a mesclagem resultante verá que você favorece o new longo do tempo. Suas fusões posteriores não verão os conflitos entre o old e o new que resultaram da sua alteração, de modo que eles não precisam sofrer.

Você está vendo um recurso de segurança do Git. O Git se recusa a atualizar o branch remoto com o seu branch, porque o head commit do seu branch não é um descendente direto do head commit atual do branch que você está enviando.

Se este não fosse o caso, então duas pessoas empurrando para o mesmo repository mais ou menos ao mesmo tempo não saberiam que havia um novo commit vindo ao mesmo tempo e quem pressionasse por último perderia o trabalho do empurrador anterior sem eles percebem isso.

Se você sabe que você é a única pessoa que está pressionando e quer empurrar um commit emendado ou empurrar um commit que retorna o branch, você pode ‘forçar’ o Git a atualizar o branch remoto usando o switch -f .

 git push -f origin master 

Mesmo isso pode não funcionar, pois o Git permite que repositorys remotos recusem envios não-rápidos na extremidade remota usando a variável de configuração receive.denynonfastforwards . Se este for o caso, o motivo da rejeição será semelhante a este (observe a parte ‘rejeitado remotamente’):

  ! [remote rejected] master -> master (non-fast forward) 

Para contornar isso, você precisa alterar a configuração do repository remoto ou, como um hack sujo, pode excluir e recriar o ramo da seguinte forma:

 git push origin :master git push origin master 

Em geral, o último parâmetro para git push usa o formato : , em que local_ref é o nome da ramificação no repository local e remote_ref é o nome da ramificação no repository remoto. Este par de comandos usa dois atalhos. :master tem um local_ref nulo, o que significa empurrar um ramo nulo para o master lado remoto, ou seja, excluir o ramo remoto. Um nome de ramificação sem : significa enviar o ramo local com o nome fornecido para o ramo remoto com o mesmo nome. master nesta situação é curto para master:master .

Rant Quick: O fato de que ninguém postou a resposta simples aqui demonstra a desesperada hostilidade do usuário exibida pelo Git CLI.

De qualquer forma, a maneira “óbvia” de fazer isso, assumindo que você não tentou forçar o push, é puxar primeiro. Isso puxa a mudança que você alterou (e assim não tem mais) para que você a tenha novamente.

Depois de ter resolvido quaisquer conflitos, você pode pressionar novamente.

Assim:

 git pull 

Se você receber erros no pull, talvez algo esteja errado na sua configuração de repository local (eu tive uma referência errada na seção de ramificação .git / config).

E depois

 git push 

Talvez você receba um commit extra com o assunto contando sobre uma “mesclagem Trivial”.

Resposta curta: não envie confirmações alteradas para um repo público.

Resposta longa: Alguns comandos do Git, como git commit --amend e git rebase , reescrevem o gráfico da história. Isso é bom, desde que você não tenha publicado suas alterações, mas, uma vez que você tenha feito isso, você realmente não deveria estar mexendo com o histórico, porque se alguém já tiver feito suas alterações, quando elas tentarem puxar novamente, pode falhar . Em vez de alterar um commit, você deve apenas fazer um novo commit com as mudanças.

No entanto, se você realmente quer enviar um commit alterado, você pode fazer assim:

 $ git push origin +master:master 

O sinal + esquerda forçará a execução do push, mesmo que isso não resulte em um commit “fast-forward”. (Um commit fast-forward ocorre quando as alterações que você está enviando são descendentes diretos das alterações que já estão no repository público.)

Aqui está uma maneira muito simples e limpa de enviar suas alterações depois de você já ter feito uma commit --amend :

 git reset --soft HEAD^ git stash git push -f origin master git stash pop git commit -a git push origin master 

Qual faz o seguinte:

  • Repor cabeça de ramificação para confirmar pai.
  • Esconder este último commit.
  • Forçar o envio para o controle remoto. O controle remoto agora não tem o último commit.
  • Pop seu stash.
  • Comprometa-se de forma limpa.
  • Empurre para o controle remoto.

Lembre-se de alterar “origem” e “mestre” se aplicar isso a uma filial ou controle remoto diferente.

Eu o resolvi descartando meu commit alterado local e adicionando as novas alterações no topo:

 # Rewind to commit before conflicting git reset --soft HEAD~1 # Pull the remote version git pull # Add the new commit on top git add ... git commit git push 

Eu tive o mesmo problema.

  • Acidentalmente emendou o último commit que já foi enviado
  • Realizamos muitas alterações localmente, comprometemos cerca de cinco vezes
  • Tentei empurrar, tenho um erro, em pânico, mesclado remoto, tenho um monte de não-meus-arquivos, empurrado, falhou, etc.

Como um Git-novato, eu pensei que era FUBAR completo.

Solução: Um pouco como @bara sugeriu + criou um ramo de backup local

 # Rewind to commit just before the pushed-and-amended one. # Replace  with the needed hash. # --soft means: leave all the changes there, so nothing is lost. git reset --soft  # Create new branch, just for a backup, still having all changes in it. # The branch was feature/1234, new one - feature/1234-gone-bad git checkout -b feature/1234-gone-bad # Commit all the changes (all the mess) not to lose it & not to carry around git commit -a -m "feature/1234 backup" # Switch back to the original branch git checkout feature/1234 # Pull the from remote (named 'origin'), thus 'repairing' our main problem git pull origin/feature/1234 # Now you have a clean-and-non-diverged branch and a backup of the local changes. # Check the needed files from the backup branch git checkout feature/1234-gone-bad -- the/path/to/file.php 

Talvez não seja uma solução rápida e limpa, e eu perdi meu histórico (1 commit ao invés de 5), mas economizei um dia de trabalho.

Se você souber que ninguém puxou o commit não alterado, use a opção --force-with-lease do git push .

No TortoiseGit, você pode fazer o mesmo em “Push …” opções “Force: May discard” e checando “mudanças conhecidas”.

Forçar (pode descartar alterações conhecidas) permite que o repository remoto aceite um push não-avanço rápido mais seguro. Isso pode fazer com que o repository remoto perca commits; use-o com cuidado. Isso pode impedir a perda de alterações desconhecidas de outras pessoas no controle remoto. Ele verifica se o ramo do servidor aponta para o mesmo commit que o branch de rastreamento remoto (mudanças conhecidas). Se sim, um empurrão de força será executado. Caso contrário, será rejeitado. Como o git não possui tags de rastreamento remoto, as tags não podem ser sobrescritas usando essa opção.

Aqui está uma maneira muito simples e limpa de enviar suas mudanças depois de você ter feito um git add "your files" e git commit --amend :

 git push origin master -f 

ou:

 git push origin master --force 

Se você não empurrou o código para sua ramificação remota (GitHub / Bitbucket), você pode alterar a mensagem de confirmação na linha de comando, conforme abaixo.

  git commit --amend -m "Your new message" 

Se você estiver trabalhando em um ramo específico, faça o seguinte:

 git commit --amend -m "BRANCH-NAME: new message" 

Se você já enviou o código com uma mensagem errada, precisa ter cuidado ao alterar a mensagem. ou seja, depois de alterar a mensagem de confirmação e tentar pressioná-la novamente, você acaba tendo problemas. Para torná-lo suave, siga os seguintes passos.

Por favor, leia a resposta inteira antes de fazer isso

 git commit --amend -m "BRANCH-NAME : your new message" git push -f origin BRANCH-NAME # Not a best practice. Read below why? 

Nota importante: Quando você usa o force push diretamente, pode acabar com problemas de código que outros desenvolvedores estão trabalhando na mesma ramificação. Então, para evitar esses conflitos, você precisa puxar o código do seu branch antes de fazer o push force :

  git commit --amend -m "BRANCH-NAME : your new message" git pull origin BRANCH-NAME git push -f origin BRANCH-NAME 

Essa é a melhor prática ao alterar a mensagem de confirmação, se já foi enviada.

Você está recebendo este erro porque o Git remoto já possui esses arquivos de confirmação. Você tem que forçar o ramo para que isso funcione:

 git push -f origin branch_name 

Além disso, certifique-se de retirar o código do controle remoto, pois alguém da sua equipe pode ter enviado para o mesmo ramo.

 git pull origin branch_name 

Este é um dos casos em que temos que forçar o envio do commit para remoto.

Eu tive que consertar este problema com puxando do repository remoto e lidar com os conflitos de mesclagem que surgiram, confirmar e depois empurrar. Mas eu sinto que há um jeito melhor.

Eu apenas continuei fazendo o que o Git me disse para fazer. Assim:

  • Não é possível enviar por causa do commit alterado.
  • Eu faço um puxão como sugerido.
  • A mesclagem falha. então eu corrijo manualmente.
  • Crie um novo commit (chamado “merge”) e pressione-o.
  • Parece funcionar!

Nota: O commit alterado foi o mais recente.

    Intereting Posts