git: Seu ramo está à frente por X confirma

Como isso realmente acontece?

Atualmente, estou trabalhando em um repositório sozinho, então este é o meu fluxo de trabalho:

1. Alterar arquivos
2. Confirmar
3. Repita 1-2 até ficar satisfeito
4. Pressione para dominar

Então, quando eu faço um git status, diz-me que meu ramo está à frente de confirmações de X (presumivelmente o mesmo número de confirmações que eu fiz). É porque, quando você pressiona o código, ele não atualiza seus arquivos armazenados em cache localmente (nas pastas .git)? git pullparece 'consertar' essa mensagem estranha, mas ainda estou curioso por que isso acontece, talvez eu esteja usando o git errado?

incluindo qual ramificação é impressa na mensagem

Minha filial local está à frente do mestre

onde você empurra / puxa o ramo atual

Estou migrando para o GitHub e acessando o computador em que estou trabalhando naquele momento, minha cópia local está sempre atualizada, pois sou a única a trabalhar nela.

na verdade, não verifica o repositório remoto

Foi isso o que pensei, pensei em garantir que meu entendimento estivesse correto.

você está passando alguns argumentos extras para ele?

Não os que eu posso ver, talvez haja alguma configuração engraçada acontecendo do meu lado?

$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

Se você receber esta mensagem depois de fazer a git pull remote branch, tente segui-la com a git fetch. (Opcionalmente, execute git fetch -pa remoção de ramificações excluídas do repositório)

A busca parece atualizar a representação local da ramificação remota, o que não acontece necessariamente quando você faz um git pull remote branch.

Usar

git pull --rebase

A opção --rebase significa que o git afastará seu commit local, sincronizará com o controle remoto e tentará aplicar seus commit no novo estado.

Use estes 3 comandos simples

Etapa 1 :git checkout <branch_name>

Etapa 2 :git pull -s recursive -X theirs

Etapa 3 :git reset --hard origin/<branch_name>

Mais detalhes: https://stackoverflow.com/a/39698570/2439715

Aproveitar.

Acho que você está interpretando mal a mensagem - seu ramo não está à frente master, está master . É antes de origin/master, que é um ramo de monitoramento remoto que registra o estado do repositório remoto de seu último push, pullou fetch. Está dizendo exatamente o que você fez; você ficou à frente do controle remoto e está lembrando que você deve empurrar.

Alguém disse que você pode estar interpretando mal sua mensagem, não está. Esse problema realmente tem a ver com seu <project>/.git/configarquivo. Nele haverá uma seção semelhante a esta:

[remote "origin"]
    url = <url>
    fetch = +refs/heads/*:refs/remotes/origin/*

Se você remover a linha de busca do arquivo .git / config do seu projeto, interromperá a opção "Sua ramificação está à frente de 'origem / mestre' N confirmação ". aborrecimento de ocorrer.

Ou assim espero. :)

Eu tive esse problema no meu servidor de palco, onde apenas puxa. E o hard reset ajudou-me a limpar o HEAD da mesma forma que o controle remoto.

git reset --hard origin/master

Então agora eu tenho novamente:

On branch master
Your branch is up-to-date with 'origin/master'.

Isso funcionou para mim

git reset --hard origin/master

A saída deve se parecer com

On branch dev HEAD is now at ae1xc41z Last commit message

No meu caso, foi porque mudei para o master usando

 git checkout -B master

Apenas para puxar a nova versão em vez de

 git checkout master

O primeiro comando redefine o chefe do mestre para minhas últimas confirmações

eu usei

git reset --hard origin/master

Para consertar isso

Passei por todas as soluções desta página e, felizmente, @ anatolii-pazhyn comentou porque sua solução foi a que funcionou. Infelizmente, não tenho reputação suficiente para votar novamente, mas recomendo tentar sua solução primeiro:

git reset --hard origin/master

O que me deu:

HEAD is now at 900000b Comment from my last git commit here

Eu também recomendo:

git rev-list origin..HEAD
# to see if the local repository is ahead, push needed

git rev-list HEAD..origin
# to see if the local repository is behind, pull needed

Você também pode usar:

git rev-list --count --left-right origin/master...HEAD
# if you have numbers for both, then the two repositories have diverged

Boa sorte

Eu tive esse mesmo problema em uma máquina Windows. Quando eu executava um git pull origin mastercomando, recebia o aviso "à frente de 'origem / mestre' por X confirma". Descobri que se eu executasse git pull origine NÃO especificasse a ramificação, não receberia mais o aviso.

Apenas lembra as diferenças entre o ramo atual e o ramo que faz a trilha atual. Forneça mais informações, incluindo o ramo impresso na mensagem e onde você pressiona / puxa o ramo atual.

Embora essa pergunta seja um pouco antiga ... eu estava em uma situação semelhante e minha resposta aqui me ajudou a corrigir um problema semelhante que tive

Primeira tentativa com push -fou forçar a opção

Se isso não funcionar, é possível que (como no meu caso) os repositórios remotos (ou melhor, as referências aos repositórios remotos que aparecem git remote -v) possam não estar sendo atualizados.

O resultado acima de seu envio sincronizar seu local / filial com seu remoto / filial, no entanto, o cache em seu repositório local ainda mostra confirmação anterior (de local / filial ... desde que apenas uma confirmação única tenha sido enviada) como HEAD.

Para confirmar o clone acima, repo em um local diferente e tente comparar o HEAD local / ramo e o HEAD remoto / ramo. Se os dois são iguais, provavelmente você está enfrentando o problema que eu fiz.

Solução:

$ git remote -v
github  git@github.com:schacon/hw.git (fetch)
github  git@github.com:schacon/hw.git (push)
$ git remote add origin git://github.com/pjhyett/hw.git
$ git remote -v
github  git@github.com:schacon/hw.git (fetch)
github  git@github.com:schacon/hw.git (push)
origin  git://github.com/pjhyett/hw.git (fetch)
origin  git://github.com/pjhyett/hw.git (push)
$ git remote rm origin
$ git remote -v
github  git@github.com:schacon/hw.git (fetch)
github  git@github.com:schacon/hw.git (push)

Agora faça o push -fseguinte

git push -f github master ### Observe que seu comando não possui originmais!

Faça um git pullagora git pull github master

em git statusreceber

# On branch master

nothing to commit (working directory clean)

Espero que isso seja útil para alguém, pois o número de visualizações é tão alto que a busca por esse erro quase sempre lista esse tópico no topo

Consulte também gitref para obter detalhes

Eu realmente tive isso acontecendo quando eu estava fazendo uma troca / verificação com o TortiseGIT.

Meu problema era que eu criei a ramificação com base em outra ramificação local. Ele criou uma entrada de "mesclagem" /.git/configque se parecia com isso:

[branch "web"]
    merge = refs/heads/develop
    remote = gitserver

Onde, sempre que eu mudei para o ramo "web", estava me dizendo que eu tinha mais de 100 confirmações antes do desenvolvimento. Bem, eu não estava mais me comprometendo a me desenvolver, e isso era verdade. Consegui simplesmente remover esta entrada e parece estar funcionando conforme o esperado. Ele está rastreando corretamente com o árbitro remoto em vez de reclamar por estar atrás do ramo de desenvolvimento.

Como Vikram disse, esse encadeamento de estouro de pilha é o principal resultado do Google ao procurar esse problema, então pensei em compartilhar minha situação e solução.

Gostaria de reiterar o mesmo que mencionado por @Marian Zburlia acima. Funcionou para mim e sugeriria o mesmo para os outros.

git pull origin develop

deve ser seguido por $ git pull --rebase.

Isso removerá os comentários que aparecerem $ git statusapós a última atração.

git fetch vai resolver isso para você

Se meu entendimento estiver correto, seu local (em cache) origin/masterestá desatualizado. Este comando atualizará o estado do repositório do servidor.

Então, quando eu faço um status de git, ele me diz que meu ramo está à frente de confirmações de X (presumivelmente o mesmo número de confirmações que eu fiz ).

Minha experiência é em um ambiente de equipe com muitos ramos. Trabalhamos em nossas próprias filiais de recursos (em clones locais) e foi uma daquelas que git statusmostraram que eu tinha 11 comprometimentos à frente. Minha suposição de trabalho, como o autor da pergunta, era que +11 era de meus próprios commits .

Aconteceu que eu havia retirado as alterações do developramo comum para o meu recurso muitas semanas antes - mas esqueci! Quando revisitei minha filial local hoje e fiz um git pull origin developnúmero saltou para +41 confirma à frente. Muito trabalho foi feito develope, portanto, meu ramo de recursos local estava ainda mais à frente do ramo de recursos no originrepositório.

Portanto, se você receber essa mensagem, lembre-se de quaisquer puxões / mesclagens que você possa ter feito de outros ramos (de sua preferência ou de outros) aos quais tenha acesso. A mensagem apenas indica que você precisa que git pushessas pullalterações sejam retornadas ao originrepositório ('ramo de rastreamento') do repositório local para sincronizar as coisas.

As respostas que sugerem git pullou git fetchestão corretas.
A mensagem é gerada quando git statusvê uma diferença entre .git/FETCH_HEADe .git/refs/remotes/<repository>/<branch>(por exemplo .git/refs/remotes/origin/master).

O último arquivo registra o HEAD da última busca (para o repositório / filial). Doing git fetchatualiza os dois arquivos no HEAD atual da ramificação.
Obviamente, se não houver nada para buscar (porque o repositório local já está atualizado), .git/FETCH_HEADisso não será alterado.

Se você receber esta mensagem após fazer uma confirmação para não rastrear o arquivo na ramificação, tente fazer alguma alteração em qualquer arquivo e execute a confirmação. Aparentemente, você não pode fazer um único commit, que inclui apenas o rastreamento de arquivos rastreados anteriormente. Finalmente, este post me ajudou a resolver todo o problema https://help.github.com/articles/removing-files-from-a-repository-s-history/ . Eu apenas tive que remover o arquivo do histórico do repositório.