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

Eu tenho um servidor de gitosis remoto e um repositório git local, e cada vez que faço uma grande alteração no meu código, enviarei as alterações para esse servidor também.

Hoje, porém, acho que mesmo tendo algumas alterações locais e me comprometendo com o repositório local, ao executá- git push origin masterlo, diz 'Tudo atualizado', mas quando uso git clonepara fazer check-out de arquivos no servidor remoto, ele 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 que o git exibe durante a execução ls-remote. Não sei 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ê está trabalhando com uma cabeça separada por acaso?

Como em:

indicando que seu último commit não é um cabeçalho de ramificação.

Aviso : o seguinte faz a git reset --hard: certifique-se de usar git stashprimeiro se desejar salvar os arquivos modificados no momento.

$ 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 <commit-id>

Conforme mencionado na git checkoutpágina do manual (ênfase minha):

Às vezes, é útil poder fazer check - out de uma confirmação que não está na ponta de uma de suas ramificações .
O exemplo mais óbvio é verificar o commit em um ponto de lançamento oficial marcado, como este:

$ git checkout v2.6.18

As versões anteriores do git não permitiam isso e pediam para você criar uma ramificação temporária usando a -bopção, mas a partir da versão 1.5.0, o comando acima desanexa o seu HEADda ramificação atual e aponta diretamente para o commit nomeado pela tag ( v2.6.18no exemplo acima).

Você pode usar todos os comandos git enquanto estiver nesse estado.
Você pode usar git reset --hard $othercommitpara se movimentar ainda mais, por exemplo.
Você pode fazer alterações e criar uma nova confirmação em cima de um HEAD desanexado .
Você pode até criar uma mesclagem usando git merge $othercommit.

O estado em que você está enquanto seu HEAD está desanexado não é registrado por nenhuma ramificação (o que é natural - você não está em nenhuma ramificação).
O que isso significa é que você pode descartar as confirmações e mesclagens temporárias, retornando para uma ramificação existente (por exemplo git checkout master) e, posteriormente, git pruneou git gccoletá-las em lixo.
Se você fez isso por engano, pode pedir ao reflog HEAD onde estava, por exemplo

$ git log -g -2 HEAD

Err .. Se você é um git noob, tem certeza que tem git commitantes git push? Eu cometi esse erro pela primeira vez!

Talvez você esteja promovendo uma nova filial local?

Um novo ramo local deve ser enviado explicitamente:

git push origin your-new-branch-name

Apenas uma dessas coisas sobre o git ... Você clona um repo, faz um branch, realiza algumas alterações, pressiona ... "Tudo está atualizado". Entendo por que isso acontece, mas esse fluxo de trabalho é extremamente hostil para os novatos.

Meu problema foi que minha filial local tinha um nome diferente da filial remota. 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-different-name/ )

Outra situação que é importante estar ciente: O tipo de estado padrão para o git é que você está trabalhando no ramo "mestre". E, em muitas situações, você se destaca como o principal ramo de trabalho (embora algumas pessoas gostem e façam outras coisas).

Enfim, isso é apenas um ramo. Portanto, uma situação em que posso entrar é:

Meu ramo ativo não é realmente o ramo mestre. ... Mas eu costumo fazer o comando: git push(e eu tinha feito anteriormente git push origin master, por isso é um atalho para isso).

Normalmente, eu estou empurrando o ramo principal para o repositório compartilhado ... o que provavelmente é uma coisa boa e limpa, no meu caso ...

Mas eu esqueci que as mudanças nas quais eu estou trabalhando ainda não estão no ramo mestre !!!

Portanto, toda vez que tento git push, e vejo "Tudo atualizado", quero gritar, mas é claro que não é culpa do git! É meu.

Então, em vez disso, mesclo meu ramo no mestre e empurro, e tudo fica feliz novamente.

$ git push origin local_branch:remote_branch

Explicação

Eu tive o mesmo erro e passei horas tentando descobrir. Finalmente encontrei. O que eu não sabia é que pressionar dessa maneira git push origin branch-xtentará procurar o branch-x localmente e depois o push para o branch-x remoto.

No meu caso, eu tinha dois URLs remotos. Fiz um checkout do ramo x para o ramo y ao tentar enviar de y local para x remoto. Recebi a mensagem de que tudo está atualizado, o que é normal, porque estava pressionando x do segundo controle remoto.

Para encurtar a história, para não cair nesse tipo de armadilha, você precisa especificar a referência de origem e a referência de destino:

$ git push origin local_branch:remote_branch

Atualizar:

Se você precisar executar esse comando toda vez que enviar sua ramificação, talvez seja necessário configurar o upstream entre sua ramificação local e remota com o seguinte:

$ git push --set-upstream origin local_branch:remote_branch

Ou

$ git push -u origin local_branch:remote_branch

Veja a resposta do VonC acima - eu precisava de uma etapa 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 <commit-id>

Fiz isso, mas quando tentei git push remoterepo master, ele disse "erro: falha ao enviar algumas referências. Para impedir que você perca o histórico, as atualizações não avançadas foram rejeitadas, mescle as alterações remotas (por exemplo, 'git pull') antes empurrando novamente. "

Então eu 'git pull remoterepo master', e isso encontrou um conflito. Fiz git reset --hard <commit-id>novamente, copiei os arquivos em conflito para uma pasta de backup, fiz git pull remoterepo masternovamente, copiei os arquivos em conflito de volta para o meu projeto, fiz git commit, então git push remoterepo master, e desta vez funcionou.

Git parou de dizer 'tudo está atualizado' - e parou de reclamar de 'encaminhamento rápido'.

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

Eu tive que git addo arquivo alterado e depois git push origin master. Começou a trabalhar a partir de então.

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

Mas de qualquer maneira, aqui está o que aconteceu comigo .. 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 nenhuma das outras respostas. Aqui está o que fiz e como corrigi-lo:

Um repositório meu foi movido recentemente, mas eu tinha uma cópia local. Eu ramifiquei do meu ramo "mestre" local e fiz algumas alterações - e então lembrei que o repositório havia sido movido. Eu costumava git remote set-url origin https://<my_new_repository_url>definir o novo URL, mas quando o empurrava, dizia "Tudo atualizado" em vez de empurrar minha nova ramificação para o mestre.

Acabei resolvendo o problema, alterando origin/masternovamente e pressionando com nomes de ramo explícitos, como este:

$ git rebase <my_branch> origin/master
$ git push origin <my_branch>

Espero que isso ajude quem teve o mesmo problema!

Super raro - mas ainda assim: no Windows, pode ser que o compact-refs tenha um ramo com uma letra maiúscula (por exemplo, dev / mybranch), enquanto a pasta refs tenha outro caso (por exemplo, dev / mybranch) quando core.ignorecase estiver definido como true .

A solução é excluir manualmente a linha relevante dos pacotes-refs . Não encontrou uma solução mais limpa.

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

Primeiro, ramifiquei uma nova ramificação local da minha antiga ramificação local (que não consegui forçar). Em seguida, enviei 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 na nova filial local em vez da antiga filial local.

No meu caso, tive 2 repositórios remotos.

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

Ambos os contratos foram iguais. Apenas um era httpsoutro era ssh. Portanto, remover o indesejável (no meu caso ssh. Desde que eu usei httpsporque sshnão estava funcionando!) Corrigiu o problema para mim.

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

[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 -amonde eu 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'

Eu enfrentei o mesmo problema. Como não adicionei alterações na área de preparação. E eu tentei diretamente enviar o código para o repositório remoto usando o comando:

git push origin master

E mostra a mensagem Everything up-to-date.

Para corrigir esse problema, tente estas etapas

1. git add .
2. git commit -m "Bug Fixed"
3. git push -u origin master

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

Eu só queria mencionar que me deparei com isso depois de ativar o Git como um CVS em uma configuração de compilação local do Jenkins. Parece que Jenkins fez check-out do commit mais recente da ramificação que eu dei e também redefiniu meu controle remoto para corresponder aos caminhos que dei ao repositório. Tive que fazer checkout do meu recurso novamente e corrigir meu URL remoto de origem com 'git remote set-url'. Não aponte uma ferramenta de construção para o seu diretório de trabalho ou você terá um mau momento. Meu controle remoto foi definido como um caminho de arquivo para o meu diretório de trabalho; portanto, ele naturalmente relatou tudo atualizado quando tentei enviar alterações com a mesma origem e destino.

Outra possibilidade é que você nomeou um diretório em seu arquivo .gitignore que foi excluído. Portanto, os novos commits não seriam enviados. Aconteceu-me que nomeei um diretório para ignorar a "pesquisa", mas também era um diretório na minha árvore de origem.

Existe uma maneira rápida que eu encontrei. Vá para a pasta .git, abra o HEADarquivo e altere o ramo em que estava novamente para dominar. Por exemplo, ref:refs/heads/master

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

Isso aconteceu (as confirmações no meu log do git não estavam no GitHub, embora o git disse que tudo estava atualizado) e estou confiante de que o problema era o Github. Não recebi nenhuma mensagem de erro no git, mas o GitHub tinha erros de status e meus commits estavam lá várias horas depois.

https://status.github.com/messages

As mensagens de status do GitHub eram:

• Estamos investigando relatórios de indisponibilidade de serviço.
• Estamos investigando problemas para acessar o GitHub.com.
• Estamos com falha no sistema de armazenamento de dados para restaurar o acesso ao GitHub.com.

Outro erro muito simples, mas noobish meu: simplesmente esqueci de adicionar um -mmodificador de mensagem no meu commit. Então eu escrevi:

git commit 'My message'

Em vez de correto:

git commit -m 'My message'

NOTA: NÃO gera erros! Mas você não vai ser capaz de empurrar seus commits e sempre obter Everything up to datevez

aqui, minha solução é diferente da acima. Eu ainda não descobri como esse problema acontece, mas eu o corrigi. um pouco inesperadamente.

agora vem o caminho:

$ git push origin  use_local_cache_v1
Everything up-to-date
$ git status
On branch test
Your branch is ahead of 'origin/use_local_cache_v1' by 4 commits.
  (use "git push" to publish your local commits)
  ......
$ git push
fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:use_local_cache_v1

To push to the branch of the same name on the remote, use

    git push origin test
    
$ git push origin HEAD:use_local_cache_v1    
Total 0 (delta 0), reused 0 (delta 0)
remote:

o comando que funciona para mim é

$git push origin HEAD:use_local_cache

（Espero que vocês resolvam esse problema o mais rápido possível)

Eu sei que é super antigo, mas no meu caso eu o consertei bastante rápido.

Eu estava recebendo esse mesmo erro ao ser um commit à frente master. Então eu encontrei a publicação atual Stack Overflow. No entanto, antes de prosseguir com as idéias sugeridas, decidi fazer um novo commit e tentar novamente com o push to origin e ele funcionou sem problemas.

Não sei por que, mas talvez seja útil para outra pessoa.

Outra possibilidade é que você tenha confirmações que não afetam o diretório que você está enviando. Então, no meu caso, eu tinha uma estrutura como

- .git
- README.md
- client/
 - package.json
 - example.js
- api/
 - requirements.txt
 - example.py

E fiz um commit para modificar mestre README.md, então corri git subtree push --prefix client heroku-client mastere recebi a mensagemEverything up-to-date

Eu estava trabalhando com o Jupyter-Notebook quando encontrei esse erro enganoso.

Não consegui resolver com as soluções fornecidas acima, pois não tinha uma cabeça desanexada nem tinha nomes diferentes para meu repo local e remoto .

Mas o que eu tinha eram os tamanhos dos meus arquivos um pouco maiores que 1 MB e o maior quase ~ 2 MB . Reduzi o tamanho do arquivo usando Como posso reduzir o tamanho do arquivo do meu notebook iPython?técnica. Ajudou a reduzir o tamanho do meu arquivo limpando as saídas. Eu era capaz de enviar o código a partir de agora, pois ele trazia o tamanho do meu arquivo em KBs.