git: votre branche est en avance de X commits
Comment cela se produit-il réellement?
Je travaille seul dans un dépôt pour le moment, voici donc mon flux de travail:
- Changer les fichiers
- Commettre
- Répéter 1-2 jusqu'à satisfaction
- Pousser à maîtriser
Ensuite, lorsque je fais un git status, il me dit que ma branche est en avance de X commet (probablement le même nombre de commits que j'ai fait). Est-ce parce que lorsque vous envoyez le code, il ne met pas à jour vos fichiers mis en cache localement (dans les dossiers .git)? git pull semble 'réparer' cet étrange message, mais je suis toujours curieux de savoir pourquoi cela se produit, peut-être que j'utilise mal le git?
y compris quelle branche est imprimée dans le message
Ma branche locale est en avance sur le maître
où poussez/tirez-vous la branche actuelle?
J'appuie sur GitHub et sur l'ordinateur sur lequel je travaille à ce moment-là. Ma copie locale est toujours à jour, car je suis le seul à le faire.
il ne vérifie pas réellement le dépôt à distance
C'est ce que je pensais, je pensais que je m'assurerais que ma compréhension était correcte.
passez-vous des arguments supplémentaires à cela?
Pas ceux que je peux voir, peut-être y a-t-il une config amusante qui se passe de mon côté?
$ git status
# On branch master
# Your branch is ahead of 'Origin/master' by 1 commit.
#
nothing to commit (working directory clean)
Si vous obtenez ce message après avoir effectué un git pull remote branch, essayez de le suivre avec un git fetch. (Éventuellement, exécutez git fetch -p pour supprimer les branches supprimées du référentiel)
Fetch semble mettre à jour la représentation locale de la branche distante, ce qui ne se produit pas nécessairement lorsque vous faites un git pull remote branch.
Utilisation
git pull --rebase
L'option --rebase signifie que git déplacera votre commit local, se synchronisera avec la télécommande, puis tentera d'appliquer vos commits à partir du nouvel état.
Utilisez ces 3 commandes simples
Étape 1 : git checkout <branch_name>
Étape 2 : git pull -s recursive -X theirs
Étape 3 : git reset --hard Origin/<branch_name>
Plus de détails: https://stackoverflow.com/a/39698570/2439715
Prendre plaisir.
Je pense que vous avez mal interprété le message - votre branche n’est pas en avance sur master, elle est égale à master. Il est en avance sur Origin/master, qui est un branche de suivi à distance qui enregistre l’état du référentiel distant à partir de votre Push, pull ou fetch. Il vous dit exactement ce que vous avez fait; vous avez l’avance sur la télécommande et cela vous rappelle de pousser.
Quelqu'un a dit que vous pourriez mal interpréter votre message, mais vous ne l'êtes pas. Ce problème concerne en fait votre fichier <project>/.git/config. Dans ce sera une section similaire à ceci:
[remote "Origin"]
url = <url>
fetch = +refs/heads/*:refs/remotes/Origin/*
Si vous supprimez la ligne d'extraction du fichier .git/config de votre projet, vous arrêtez le message "Votre branche est en avance sur 'Origine/maître' de N commit." gêne de se produire.
Ou alors j'espère. :)
J'ai eu ce problème sur mon serveur de scène où je ne tire que. Et la réinitialisation matérielle m'a aidé à nettoyer HEAD pour qu'il soit identique à celui de la télécommande.
git reset --hard Origin/master
Alors maintenant j'ai encore:
On branch master
Your branch is up-to-date with 'Origin/master'.
Dans mon cas, c’est parce que je suis passé au master en utilisant
git checkout -B master
Juste pour en tirer la nouvelle version au lieu de
git checkout master
La première commande réinitialise la tête du maître à mes derniers commits
J'ai utilisé
git reset --hard Origin/master
Pour résoudre ce problème
J'ai parcouru chaque solution sur cette page et, heureusement, @ anatolii-pazhyn a commenté car sa solution était celle qui fonctionnait. Malheureusement, je n'ai pas assez de réputation pour le remplacer, mais je vous recommande d'essayer d'abord sa solution:
git reset --hard Origin/master
Ce qui m'a donné:
HEAD is now at 900000b Comment from my last git commit here
Je recommande aussi:
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
Vous pouvez aussi utiliser:
git rev-list --count --left-right Origin/master...HEAD
# if you have numbers for both, then the two repositories have diverged
Bonne chance
J'ai eu le même problème sur une machine Windows. Lorsque j'exécutais une commande git pull Origin master, j'obtenais l'avertissement "avant" Origine/maître "de X commits". J'ai découvert que si, au lieu de cela, je exécutais git pull Origin et ne spécifiais PAS la branche, je ne recevrais plus l'avertissement.
Ensuite, lorsque je fais un statut git, il me dit que ma branche est en avance de X commits (probablement le même nombre de commets que j'ai faits).
Mon expérience est dans un environnement d'équipe avec de nombreuses branches. Nous travaillons dans nos propres branches de fonctionnalités (dans des clones locaux) et c’est l’une de celles que git status a montré que j’avais 11 commits de plus. Mon hypothèse de travail, à l'instar de l'auteur de la question, était que +11 venait de commets de ma propre initiative.
Il s’est avéré que j’avais introduit des changements de la branche courante develop dans ma branche d’entités plusieurs semaines auparavant - mais j'ai oublié! Lorsque j'ai revisité ma branche de fonctionnalité locale aujourd'hui et que j'ai effectué un git pull Origin develop, le nombre a grimpé à +41 avant. Beaucoup de travail avait été fait dans develop et ma branche de fonctions locale était donc encore plus avancée que celle du référentiel Origin.
Donc, si vous recevez ce message, repensez à tous les mouvements que vous pourriez avoir réalisés à partir d’autres branches (de la vôtre ou d’autres) auxquelles vous avez accès. Le message signale simplement que vous devez git Push ces pulled revenir au Origin repo ("branche de suivi") de votre référentiel local pour que les éléments soient synchronisés.
Cela vous rappelle simplement les différences entre la branche en cours et la branche qui fait la piste en cours. Veuillez fournir plus d'informations, y compris quelle branche est imprimée dans le message et où poussez/retirez-vous la branche actuelle.
Bien que cette question soit un peu vieille ... j'étais dans une situation similaire et ma réponse ici m'a aidé à résoudre un problème similaire que j'avais
Essayez d'abord avec Push -f ou une option de force
Si cela ne fonctionne pas, il est possible que (comme dans mon cas) les référentiels distants (ou plutôt les références aux référentiels distants qui apparaissent sur git remote -v) ne soient pas mis à jour.
Le résultat ci-dessus étant votre Push. Votre synchronisation/branche locale/votre branche distante a été synchronisée. Toutefois, le cache de votre référentiel local indique toujours la validation précédente (de la section locale/branche ... à condition que seule la validation ait été poussée) sous la forme HEAD.
Pour confirmer la réplique ci-dessus, clonez le référentiel à un emplacement différent et essayez de comparer le répertoire local/branche HEAD et le type distant/branche HEAD. Si les deux sont identiques, vous êtes probablement confronté au problème que j'ai rencontré.
Solution:
$ git remote -v
github [email protected]:schacon/hw.git (fetch)
github [email protected]:schacon/hw.git (Push)
$ git remote add Origin git://github.com/pjhyett/hw.git
$ git remote -v
github [email protected]:schacon/hw.git (fetch)
github [email protected]: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 [email protected]:schacon/hw.git (fetch)
github [email protected]:schacon/hw.git (Push)
Maintenant, faites un Push -f comme suit
git Push -f github master ### Notez que votre commande n'a plus Origin!!
Faites un git pull maintenant git pull github master
sur git status recevoir
# On branch master
nothing to commit (working directory clean)
J'espère que cela sera utile pour quelqu'un car le nombre de vues est si élevé que la recherche de cette erreur liste presque toujours ce fil au sommet.
Voir aussi gitref pour plus de détails
En fait, cela se produisait lorsque je faisais un changement/un contrôle avec TortiseGIT.
Mon problème était que j'avais créé la branche basée sur une autre branche locale. Il a créé une entrée "fusion" dans /.git/config qui ressemblait à ceci:
[branch "web"]
merge = refs/heads/develop
remote = gitserver
À chaque fois que je passais à la branche "Web", cela me disait que j'avais plus de 100 commits avant de se développer. Eh bien, je ne m'engageais plus à développer alors c'était vrai. J'ai pu simplement supprimer cette entrée et elle semble fonctionner comme prévu. Il effectue un suivi correct avec le ref distant au lieu de se plaindre d'être derrière la branche de développement.
Comme l'a dit Vikram, ce fil de discussion Stack Overflow est le meilleur résultat de Google lors de la recherche de ce problème. J'ai donc pensé partager ma situation et ma solution.
_git fetch_ va résoudre ce problème pour vous
Si j'ai bien compris, votre __ local (mis en cache) _Origin/master_ est obsolète. Cette commande mettra à jour l'état du référentiel à partir du serveur.
Je voudrais réitérer la même chose que celle mentionnée par @Marian Zburlia ci-dessus. Cela a fonctionné pour moi et suggérerait la même chose aux autres.
git pull Origin develop
doit être suivi de $ git pull --rebase.
Cela supprimera les commentaires sur le $ git status après le dernier tirage.
Cela a fonctionné pour moi
git reset --hard Origin/master
La sortie doit ressembler à
On branch dev HEAD is now at ae1xc41z Last commit message
Les réponses suggérant git pull ou git fetch sont correctes.
Le message est généré lorsque git status voit une différence entre .git/FETCH_HEAD et .git/refs/remotes/<repository>/<branch> (par exemple .git/refs/remotes/Origin/master).
Ce dernier fichier enregistre le HEAD de la dernière extraction (pour le référentiel/la branche). Faire git fetch met à jour les deux fichiers dans la HEAD actuelle de la branche.
Bien sûr, s'il n'y a rien à récupérer (car le référentiel local est déjà à jour), alors .git/FETCH_HEAD ne change pas.
Si vous recevez ce message après une validation afin de désarchiver un fichier dans la branche, essayez de modifier quelque fichier que ce soit et effectuez une validation. Apparemment, vous ne pouvez pas effectuer une seule validation, ce qui inclut uniquement le retrait du suivi du fichier précédemment suivi. Enfin, cet article m'a aidé à résoudre tout le problème https://help.github.com/articles/removing-files-from-a-repository-s-history/ . Je viens juste de supprimer un fichier de l'historique du référentiel.