git push diz tudo atualizado, mesmo que eu tenha alterações locais

Eu tenho um servidor de gitoses remoto e um repository git local, e cada vez que eu faço uma grande mudança no meu código, eu vou empurrar as mudanças para esse servidor também.

Mas hoje eu acho que mesmo que eu tenha algumas mudanças locais e se comprometa com o repository local, ao executar o git push origin master ele diz ‘Tudo atualizado’, mas quando eu uso o git clone para fazer checkout de arquivos no servidor remoto, não contém as alterações mais recentes. E eu tenho apenas um ramo chamado mestre e um servidor remoto chamado origem.

PS: Isso é o que o git exibe ao executar ls-remote, não tenho certeza se isso ajuda

$ git ls-remote origin df80d0c64b8e2c160d3d9b106b30aee9540b6ece HEAD df80d0c64b8e2c160d3d9b106b30aee9540b6ece refs/heads/master $ git ls-remote . 49c2cb46b9e798247898afdb079e76e40c9f77ea HEAD df80d0c64b8e2c160d3d9b106b30aee9540b6ece refs/heads/master df80d0c64b8e2c160d3d9b106b30aee9540b6ece refs/remotes/origin/master 3a04c3ea9b81252b0626b760f0a7766b81652c0c refs/tags/stage3 

Você não estaria trabalhando com uma cabeça imparcial por acaso?

Como em:

cabeça solta

indicando que seu commit mais recente não é um branch head.

 $ git log -1 # note the SHA-1 of latest commit $ git checkout master # reset your branch head to your previously detached commit $ git reset --hard  

Como mencionado na página man git checkout (ênfase minha):

Às vezes, é útil poder verificar um commit que não esteja na ponta de um de seus branches .
O exemplo mais óbvio é verificar o commit em um ponto de release oficial marcado, assim:

 $ git checkout v2.6.18 

Versões anteriores do git não permitiram isso e pediram que você criasse uma ramificação temporária usando a opção -b , mas a partir da versão 1.5.0, o comando acima separa seu HEAD da ramificação atual e aponta diretamente para a confirmação nomeada pela tag ( v2.6.18 no exemplo acima).

Você pode usar todos os comandos do git enquanto estiver neste estado.
Você pode usar o git reset --hard $othercommit para se movimentar, por exemplo.
Você pode fazer alterações e criar um novo commit em cima de um HEAD separado .
Você pode até mesmo criar uma mesclagem usando o git merge $othercommit .

O estado em que você está enquanto sua CABEÇA é separada não é registrado por nenhum ramo (o que é natural – você não está em nenhum ramo).
O que isto significa é que você pode descartar seus commits temporários e mesclagens mudando de volta para um branch existente (por exemplo, git checkout master ), e um git prune posterior ou git gc os garbage collection.
Se você fez isso por engano, você pode perguntar ao reflog para HEAD onde você estava, por exemplo

 $ git log -g -2 HEAD 

Err .. Se você é um gob noob, tem certeza que tem git commit antes do git push ? Eu cometi este erro pela primeira vez!

Talvez você esteja empurrando um novo ramo local?

Uma nova ramificação local deve ser enviada explicitamente:

 git push origin your-new-branch-name 

Apenas uma daquelas coisas sobre o git … Você clona um repo, faz um branch, comete algumas mudanças, empurra … “Tudo está atualizado”. Eu entendo porque isso acontece, mas este stream de trabalho é extremamente hostil para os recém-chegados.

Outra situação que é importante estar ciente: O tipo de estado padrão para o git é que você está trabalhando na ramificação “master”. E, para muitas situações, você simplesmente ficará nesse ramo principal (embora algumas pessoas se interessem e façam outras coisas).

De qualquer forma, isso é apenas um ramo. Então, uma situação que eu possa entrar é:

Meu branch ativo na verdade NÃO é o branch master. … Mas eu costumo fazer o comando: git push (e eu já havia feito o git push origin master , então é um atalho para THAT).

Então, eu normalmente estou empurrando o branch master para o repository compartilhado … o que é provavelmente uma coisa boa e limpa, no meu caso …

Mas eu esqueci que as mudanças nas quais tenho trabalhado ainda não estão no ramo master !!!

Então, toda vez que eu tento git push , e eu vejo “Tudo atualizado”, eu quero gritar, mas é claro, não é culpa do idiota! É meu.

Então, em vez disso, eu mesclar meu ramo em mestre, e depois empurrar, e tudo é feliz novamente.

Meu problema era que minha filial local tinha um nome diferente do ramo remoto. Eu fui capaz de fazer o seguinte:

$ git push origin local-branch-name:remote-branch-name

(Crédito para https://penandpants.com/2013/02/07/git-pushing-to-a-remote-branch-with-a-nome-diferente/ )

Veja a resposta de VonC acima – eu precisava de um passo extra:

 $ git log -1 - note the SHA-1 of latest commit $ git checkout master - reset your branch head to your previously detached commit $ git reset --hard  

Eu fiz isso, mas quando eu tentei git push remoterepo master , ele disse “erro: não conseguiu empurrar alguns refs. Para impedir que você perca o histórico, não-fast forward atualizações foram rejeitadas, Mesclar as mudanças remotas (por exemplo, ‘git puxar ‘) antes de empurrar novamente. “

Então eu fiz ‘puxar remoterepo mestre’, e encontrou um conflito. Eu fiz git reset --hard novamente, copiei os arquivos conflitantes para uma pasta de backup, fiz git pull remoterepo master novamente, copiei os arquivos conflitantes de volta para o meu projeto, fiz git commit , depois git push remoterepo master , e desta vez funcionou.

Git parou de dizer “tudo está em dia” – e parou de reclamar de “fast forward”.

Eu enfrentei uma situação semelhante; quando eu fiz as mudanças e tentei git push origin master , ele estava dizendo que tudo estava atualizado.

Eu tive que git add o arquivo alterado e, em seguida, git push origin master . Começou a trabalhar a partir de então.

Do seu status de git, você provavelmente tem uma situação diferente da minha.

Mas de qualquer maneira, aqui está o que aconteceu comigo .. Eu encontrei o seguinte erro:

 fatal: The remote end hung up unexpectedly Everything up-to-date 

A mensagem mais informativa aqui é que o controle remoto desligou. Acontece que é devido a exceder o tamanho do buffer de postagem http. A solução é aumentá-lo com

git config http.postBuffer 524288000

Eu tive esse problema hoje e não teve nada a ver com as outras respostas. Aqui está o que eu fiz e como consertei:

Um repository meu recentemente mudou, mas eu tinha uma cópia local. Saí do meu ramo “mestre” local e fiz algumas alterações – e então me lembrei que o repository havia se movido. Eu usei o git remote set-url origin https:// para definir o novo URL, mas quando eu empurrei apenas diria “tudo atualizado” em vez de empurrar minha nova ramificação para mestre.

Eu acabei resolvendo isso rebasing para origin/master e depois empurrando com nomes explícitos de ramificações, como este:

 $ git rebase  origin/master $ git push origin  

Espero que isso ajude alguém que teve o mesmo problema!

 $ git push origin local_branch:remote_branch 

Explicação

Eu tive o mesmo erro e passei horas tentando descobrir isso. Finalmente encontrei. O que eu não sabia é que pressionar assim como o git push origin branch-x tentará procurar por branch-x localmente e então empurrar para branch-x remoto.

No meu caso, eu tinha duas URLs remotas. Eu fiz um checkout de branch-x para branch-y ao tentar empurrar de y localmente para x remote Eu tive a mensagem de que tudo está atualizado, o que é normal porque eu estava empurrando para x do segundo controle remoto.

Resumindo a história para não cair nesse tipo de armadilha, você precisa especificar a ref de origem e a ref de destino:

 $ git push origin local_branch:remote_branch 

Super raro – mas ainda assim: No Windows, pode ser que o refs-embalado tenha uma ramificação com um caso de letra (ie dev / mybranch), enquanto a pasta refs tem outro caso (ie Dev / mybranch) quando core.ignorecase é definido como true .

A solução é excluir manualmente a linha relevante de refs compactados . Não encontrou uma solução mais limpa.

Outra possibilidade é que você nomeou um diretório em seu arquivo .gitignore que foi excluído. Então os novos commits não seriam empurrados. Aconteceu-me que eu nomeei um diretório para ignorar “search”, mas esse também era um diretório na minha tree de fonts.

Meu erro foi diferente de tudo até agora mencionado. Se você não tem idéia de por que você teria uma cabeça imparcial, então você provavelmente não tem. Eu estava trabalhando no piloto automático com git commit e git push , e não tinha lido a saída do git commit . Acontece que foi uma mensagem de erro porque eu esqueci-me.

 [colin] ~/github/rentap.js [master] M % git commit 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers' error: pathspec 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers' did not match any file(s) known to git. [colin] ~/github/rentap.js [master] M % git push Enter passphrase for key '/home/colin/.ssh/id_ecdsa': Everything up-to-date 

Corrigido colocando -am onde costumo fazer:

 [colin] ~/github/rentap.js [master] M % git commit -am 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers' 

Verifique se você não utilizou seu URL remoto.

Eu só queria mencionar também que eu corri para isso depois de ativar o Git como um CVS em uma configuração local de configuração do Jenkins. Parece que Jenkins verificou o commit mais recente do branch que eu dei e também redefiniu meu remote para corresponder aos caminhos que eu dei para o repo. Tive que verificar meu ramo de resources novamente e corrigir meu URL remoto de origem com ‘git remote set-url’. Não vá apontando uma ferramenta de construção para o seu diretório de trabalho ou você terá um mau momento. Meu controle remoto foi configurado para um caminho de arquivo para o meu diretório de trabalho, portanto, ele relatou tudo naturalmente quando tentei enviar alterações com a mesma origem e destino.

Eu me deparei com isso quando fundei um branch no Github e continuei a desenvolvê-lo localmente. Minha correção foi um pouco diferente das outras que foram sugeridas.

Primeiro ramifiquei um novo ramo local do meu antigo ramo local (que eu não pude empurrar). Então eu empurrei a nova ramificação local para o servidor de origem (Github). Ou seja

 $ git checkout -b newlocalbranch oldlocalbranch $ git push origin newlocalbranch 

Isso fez com que as mudanças aparecessem no Github, embora em um novo ramo local, em vez de um velho ramo local.

No meu caso eu tive 2 repos remotos.

 git remote -v originhttps https://asim_kt@... originhttps https://asim_kt@... origin ssh:git@bitbucket.org:... origin ssh:git@bitbucket.org:... 

Ambos repo foi o mesmo. Apenas um era o outro https ssh . Então, removendo o indesejado, (No meu caso ssh . Desde que eu usei https porque ssh não estava funcionando!) Corrigido o problema para mim.

Eu tive o mesmo problema. No meu caso, foi causado por ter nomes para o mesmo controle remoto. Ele criou o padrão ‘origem’, mas eu tenho usado ‘github’ como meu controle remoto por um longo tempo, então isso também estava lá. Assim que eu removi o controle remoto ‘origin’, o erro foi embora.

Há uma maneira rápida que encontrei. Vá para a sua pasta .git, abra o arquivo HEAD e altere o branch que você estava de volta para master. Por exemplo ref: refs/heads/master