Pourquoi ne Git dire que ma branche principale est “à jour”, même si elle ne l'est pas?

Problème De Base

Je viens de supprimer TOUT le code à partir d'un fichier dans mon projet et engage le changement de mon git local (sur le but). Je n'ai

git pull upstream master

d'extraction et de fusion de l'amont (donc, en théorie, qui a supprimé le code devrait être de retour).

Git me dit que tout est à jour.

Tout ce qui n'est certainement PAS à jour tout ce qui supprimés code est toujours supprimé.

D'Autres Informations Pertinentes

Je n'ai qu'une branche appelée "maître".

J'ai récemment mis en place des "maître" de la piste en amont de la sorte:

Branche master mis en place pour le suivi à distance de la branche master de l'amont.

La commande git branch -vv rendements:

* master 7cfcb29 [upstream/master: ahead 9] deletion test

Pourquoi pourquoi pourquoi est-ce arrivé? Je suis sur le point de tout e-mailing mon chef de projet des modifications que je fais sur notre code.

Mise à jour

Je pensais que c'était évident, mais de toute façon c'est mon but:

Obtenir la plus récente du code sur mon système.

Excusez ma colère ici, mais pourquoi une simple tâche d'avoir à être si difficile?

Il est évident que si vous supprimez votre source puis essayez de tirer avec un simple "pull" qui git ne sera pas annuler vos modifications locales (dans ce cas, votre suppressions) sans s'assurer que vous voulez vraiment pour annuler vos modifications locales. La première réponse semble expliquer exactement comment vous pouvez aller à ce sujet.

InformationsquelleAutor user1971506 | 2013-03-13

189

Je pense que votre question fondamentale ici est que vous êtes de mauvaise interprétation et/ou de l'incompréhension de ce que git fait et pourquoi il le fait.

Lorsque vous clonez certains autres référentiel git fait une copie de tout ce qui est "là-bas". Il prend également "leur" branche des étiquettes, telles que master, et fait une copie de ce label dont le "nom complet" dans votre arbre git est (normalement) remotes/origin/master (mais dans votre cas, remotes/upstream/master). La plupart du temps vous obtenez à omettre la remotes/ partie trop, de sorte que vous pouvez vous référer à cet original comme upstream/master.

Si maintenant vous faire et commettre des changement(s) de fichier(s), vous êtes le seul avec ces changements. Parallèlement, d'autres personnes peuvent utiliser le dépôt original (à partir de laquelle vous avez fait votre clone) pour faire d'autres clones et du changement de ces clones. Ils sont les seuls, avec leurs modifications, bien sûr. Finalement, si, quelqu'un peut-être des modifications ils renvoient le propriétaire d'origine (par l'intermédiaire de "pousser" ou des patchs ou autre).

La git pull de commande est la plupart du temps juste un raccourci pour git fetch suivie par git merge. Ceci est important car il signifie que vous devez comprendre ce que ces deux opérations réellement faire.

La git fetch commande dit de retourner à l'endroit où vous cloné à partir de (ou ont par ailleurs mis en place comme un lieu de chercher à partir de) et de trouver "de nouveaux trucs à quelqu'un d'autre ajouté ou modifié ou supprimé". Ces changements sont copiées et appliquée à votre copie de ce que vous avez auparavant. Ils sont pas appliqué à votre propre travail, uniquement à la leur.

La git merge de commande est plus compliqué et c'est là que vous allez mal. Ce qu'il fait, simpliste, un peu, est de comparer ce que vous avez changé dans votre copie" à "modifications que vous avez récupérée à partir de quelqu'un d'autre et ainsi ont été ajoutés à votre-copie-de-la-quelqu'un-autre-travaux". Si vos modifications et leurs modifications ne semblent pas en conflit, le merge opération mushes ensemble et vous donne une "fusion s'engager" que les liens de votre développement et de leur développement (bien qu'il soit très commun de "facile" au cas où vous n'avez pas de changements, et vous obtenez un "fast forward").

La situation que vous êtes à la rencontre de maintenant est celui dans lequel vous avez effectué des modifications et commis—neuf fois, en fait, d'où le "à venir 9"—et ils ont fait pas changements. Donc, fetch consciencieusement récupère rien, et puis merge prend leurs manque de modifications et ne fait rien.

Ce que vous voulez, c'est de regarder, ou peut-être même "reset" pour, "leur" version du code.

Si vous voulez simplement pour regarder, vous pouvez simplement vérifier que version:
```
git checkout upstream/master
```
Qui indique à git que vous voulez déplacer le répertoire en cours à la direction générale dont le nom complet est en fait remotes/upstream/master. Vous verrez leur code de la dernière fois que vous avez exécuté git fetch et ont obtenu leur code plus tard.

Si vous voulez abandonner tous vos propres changements, ce que vous devez faire est de changer git de l'idée de la révision de votre étiquette, master, doit nom. Actuellement, il noms de votre dernier commit. Si vous obtenez de retour sur cette branche:
```
git checkout master
```
puis le git reset commande vous permet de "déplacer l'étiquette", comme elle l'avait fait. Le seul problème restant (en supposant que vous êtes vraiment prêt à abandonner tout ce que vous avez don) est de trouver l'endroit où l'étiquette doit pointer.

git log vous permettra de trouver le numérique noms—les choses comme 7cfcb29—qui sont permanents (qui ne change jamais) les noms, et il y a un nombre ridicule de d'autres façons de les nommer, mais dans ce cas, vous voulez juste le nom upstream/master.

Pour déplacer l'étiquette, de l'anéantissement de vos propres changements (tout ce que vous avez commises sont effectivement récupérable pour un bon moment, mais il est beaucoup plus difficile après cela donc être très sûr):
```
git reset --hard upstream/master
```
La --hard indique à git pour effacer ce que vous avez fait, la direction générale de l'étiquette, et de vérifier ensuite la validation donnée.

C'est pas super commun à vraiment voulez git reset --hard et effacer un tas de travail. Une méthode plus sûre (ce qui rend beaucoup plus facile de récupérer ce travail si vous décider de cela en vaut la peine, après tout) est de renommer votre branche:
```
git branch -m master bunchofhacks
```
et ensuite faire une nouvelle branche locale nommée master que les "pistes" (je n'aime pas vraiment ce terme car je pense qu'il confond les gens, mais c'est le git terme 🙂 ) l'origine (ou en amont) le maître:
```
git branch -t master upstream/master
```
et vous pourrez vous-même avec:
```
git checkout master
```
Ce que les trois dernières commandes de le faire (il y a des raccourcis pour deux commandes) est de changer le nom collé sur l'étiquette existante, puis faire une nouvelle étiquette, puis de passer à ça:

avant de faire quoi que ce soit:
```
C0 -    "remotes/upstream/master"
    \
     \- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 --- C8 --- C9    "master"
```
après git branch -m:
```
C0 -    "remotes/upstream/master"
    \
     \- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 --- C8 --- C9    "bunchofhacks"
```
après git branch -t master upstream/master:
```
C0 -    "remotes/upstream/master", "master"
    \
     \- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 --- C8 --- C9    "bunchofhacks"
```
Ici C0 est le dernier commit (une source complète de l'arbre) que vous avez lorsque vous avez fait votre git clone. C1-C9 sont vos commits.

Notez que si vous étiez à git checkout bunchofhacks et puis git reset --hard HEAD^^, ce serait de modifier la dernière image de:
```
C0 -    "remotes/upstream/master", "master"
    \
     \- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 -    "bunchofhacks"
                                                      \
                                                       \- C8 --- C9
```
La raison en est que HEAD^^ noms de la révision de deux de la tête de la branche courante (qui vient avant la réinitialisation serait bunchofhacks), et reset --hard se déplace ensuite l'étiquette. S'engage C8 et C9 sont maintenant la plupart du temps invisible (vous pouvez utiliser des choses comme le reflog et git fsck de les trouver, mais il n'est plus trivial). Vos étiquettes sont à vous déplacer comme vous le souhaitez. Le fetch commande prend soin de ceux qui commencent avec remotes/. C'est classique pour correspondre à "la vôtre" avec "leurs" (si ils ont un remotes/origin/mauve vous auriez le nom de vôtre mauve trop), mais vous pouvez taper dans "leurs" chaque fois que vous voulez le nom/voir vous engage a obtenu "d'eux". (Rappelez-vous que "un commit" est un ensemble de l'arborescence source. Vous pouvez choisir un fichier à partir d'un commit, avec git show par exemple, si et quand vous voulez.)
- J'ai beaucoup appris de votre excellente réponse. Mais je suis encore confus quant à pourquoi je reçois le git status message: "Votre branche est à jour avec 'origin/master'" quand l'amont repo est plusieurs commits avant de mon actuel des pensions. Je peux obtenir à jour avec la commande git pull, mais comment puis-je savoir que j'ai besoin de tirer si le message dit que je suis à jour?
- il semble que vous êtes en cours d'exécution git merge comme une commande de ligne de commande (ce qui est quelque chose que je fais moi-même, c'est une méthode raisonnable). Notez, cependant, que git pull commence par la première exécution de git fetch, puis en cours d'exécution git merge (ou git rebase si vous lui dites de le faire à la place). C'est le fetch étape qui apporte réellement au cours de la nouvelle s'engage à être fusionnés (ou relocalisée seule).
- Est-il une commande, autres que git status, que je peux utiliser pour voir si, en amont, les pensions de titres sont en avance de mon repo? Le message que je reçois avec git status qui dit "Votre branche est à jour avec 'origin/master'" me confond en pensant que j'ai les derniers changements, quand je n'en ai pas. Parfois, je reçois un message qui dit quelque chose comme "origin/master est de 5 s'engage à l'avance de votre branche" (paraphrase). Mais il n'est pas cohérent.
- C'est une paire de commandes, git fetch d'abord, puis git status. Vous pouvez faire un alias qui fait les deux, si vous le souhaitez. Il y a aussi git ls-remote, qui obtiendra le SHA-1 à partir de la télécommande (c'est la première étape d'un véritable git fetch), mais ceux-ci sont assez inutile pour l'homme, et si votre réseau est rapide, complet git fetch n'est pas beaucoup plus lent (et utile), alors vous devriez probablement juste git fetch.
- Oh! Maintenant, je comprends votre première réponse pour moi. Je n'ai jamais utilisé git fetch autonome de commande. Maintenant j'ai compris! Merci!
- BTW ce commentaire avec "(ou relocalisée uniquement)" a un cerveau-o (amateur version de faute de frappe), il devrait dire "(ou relocalisée-sur)".
- Puis-je supprimer une banchofhacks après toutes les étapes ci-dessus avec git branch-d banchofhacks?
- oui, à condition d'avoir d'abord vérifié un certain nombre d'autres nom de la branche (Git ne vous laisseront pas de supprimer le courant de la branche). À noter que la suppression de la nom peut faire l'commet eux-mêmes "inaccessible", dans Git de la terminologie. Si oui, ceux qui s'engage à devenir admissibles à ce que Git appelle garbage collection. Si vous ne voulez pas ou besoin de plus, c'est probablement ce que vous voulez de toute façon.
- Je viens de créer angulaire composants pour tester une application, mais pour supprimer un composant qui a été générée automatiquement par la CLI, j'ai dû aller dans tous les fichiers où angulaire du fait des changements. j'ai donc pensé à tout simplement supprimer cette branche complètement, Merci pour la rapide de l'interaction.
- Ce n'est toujours pas réellement de réponse pourquoi git status dit: "Votre direction est jusqu'à ce jour" quand immédiate git fetch puis tire vers le bas plus d'une centaine d'objets et résout près d'une centaine de deltas, mentionne plusieurs nouvelles branches et un couple de nouvelles balises et les changements de la main (suivi à distance) chef de la direction générale de commettre - et puis un autre git status cheerily, et hypocritement, dit encore "Votre direction est jusqu'à ce jour". Clairement beaucoup descendit de l'origine, mais la direction a "jusqu'à date avec mention de leur origine", à la fois avant et après?
- il y a beaucoup de façons de penser, mais peut-être le plus important, c'est ceci: votre branche master n'est pas le même que leurs branche master. Dans ce cas, il y a deux "eux"—origin et upstream—il y a donc trois masters; et votre maître n'est pas encore associé à l'un de ces trois masters. est, l'un des trois, et est associé à un autre, mais pas avec le troisième. Pas tous les cas de tomber dans ce piège particulier, mais si vous avez à la fois origin et upstream, certains le font.
- Merci @torek, je l'ai trouvé un peu de clarté ici: stackoverflow.com/questions/37694515/... Le point critique de réaliser est le "suivi à distance de la branche" est en fait local et pas maintenu automatiquement à jour. Avant la fetch la git status est juste la comparaison de la local (à distance) suivi de la branche, qui est toujours l'ancienne. status ne se compare pas à la réel branche distante. Le fetch apporte les modifications à partir de la distance à la local (à distance) de suivi de la branche et puis status peut faire sens.
- grande réponse git fetch avec git pull est le tour est joué
- Le TL;DR, c'est qu'il est jusqu'à date. Git est correct. Le ci-dessus est tout au sujet de pourquoi Git est correct et comment indiquer à Git que vous voulez quelque chose d'autre que ce qu'il est déjà en train de faire.
- Ok désolé, je pense que ma question est différente. Je me demandais pourquoi git dit $ git status On branch release/2019 Your branch is up to date with 'origin/release/2019'. Il dit que c'est jusqu'à ce jour, mais quand je tire il tire encore les choses. $ git pull remote: Counting objects: 32, done.
- git pull s'exécute git fetch d'abord, puis git merge (ou d'autres, deuxième de la commande de votre choix). Le git fetch étape à jour votre Git dans la mémoire de l' leurs Git de l'état, par l'appel de leurs Git et arriver à quelque chose de nouveau à partir d'eux. Votre git status vérifie seulement votre Git la mémoire de leurs Git.
InformationsquelleAutor torek
8

J'ai eu le même problème que vous.

Je n'ai git status git fetch git pull, mais ma branche était encore derrière à l'origine. J'ai eu des dossiers et des fichiers poussé à distance et j'ai vu les fichiers sur le web, mais sur mon local ils étaient manquants.

Enfin, ces commandes de mise à jour de tous les fichiers et dossiers sur mon local:
```
git fetch --all
git reset --hard origin/master 
```
ou si vous voulez une branche
```
git checkout your_branch_name_here
git reset --hard origin/your_branch_name_here
```
- merci! cela a effectivement travaillé. Gardez à l'esprit que la direction générale des noms sont sensibles à la casse!
InformationsquelleAutor jturi
4

Toutes les modifications que vous avez commis, comme la suppression de tous les fichiers de votre projet, sera toujours en place après un pull. Tous un pull n'est de fusionner les modifications les plus récentes à partir de quelque part d'autre dans votre propre branche, et si votre succursale a supprimé tout, puis, au mieux, vous obtiendrez des conflits de fusion lorsque l'amont changements affectent les fichiers que vous avez supprimé. Donc, en bref, oui tout est à jour.

Si vous décrivez ce que le résultat vous plaît, au lieu de "tous les fichiers supprimés", peut-être quelqu'un capable de proposer un plan d'action approprié.

Mise à jour:

OBTENIR LA PLUS RÉCENTE DU CODE SUR MON SYSTÈME

Ce que vous ne semblez pas comprendre, c'est que vous avez déjà la plus récente du code, qui est la vôtre. Si ce que vous voulez vraiment est de voir le plus récent de de quelqu'un d'autre de travail sur la branche master, il suffit de faire:
```
git fetch upstream
git checkout upstream/master
```
Noter que ce ne sera pas vous laisser dans une position immédiatement (re)démarrer votre propre travail. Si vous avez besoin de savoir comment faire pour annuler quelque chose que vous avez fait ou autrement annuler les changements que vous ou quelqu'un d'autre l'ont fait, alors s'il vous plaît fournir des détails. Aussi, pensez à lire jusqu'à ce que le contrôle de version est pour, puisque vous semblez méconnaître son objectif de base.
- Je ne veux la version la plus récente de quelqu'un d'autre code sur mon système. Cependant, ces deux commandes ne l'a pas fait. Tout ce que j'obtiens est "déjà sur la branche master". Le code dans mes fichiers ne reflète pas celle de l'autre personne code.
- Désolé, doit avoir été upstream/master. Mise à jour de ma réponse.
- git fetch origin a fait un truc pour moi!!!
InformationsquelleAutor Ryan Stewart
3

Comme les autres posters dire, tirez fusionne les modifications de l'amont à votre référentiel. Si vous souhaitez remplacer ce qui est dans votre espace de stockage avec ce qui est en amont, vous avez plusieurs options. En improvisant, j'irais avec
```
git checkout HEAD^1  # Get off your repo's master.. doesn't matter where you go, so just go back one commit
git branch -d master  # Delete your repo's master branch
git checkout -t upstream/master  # Check out upstream's master into a local tracking branch of the same name
```
InformationsquelleAutor Paul
1

Quelqu'un s'il vous plaît corrigez-moi si je me trompe, mais je crois que c'est parce que votre direction est en avance de l'amont branche master par 9 s'engage. Quand vous faites une traction à partir de la télécommande, vous disposez déjà de ces changements, c'est juste que vous êtes devant eux par 9 s'engage. Il ne serait pas logique pour ces vieux changements que vous avez déjà dans votre histoire et sont en avance par 9 s'engage, pour remplacer vos nouveaux changements.

Je crois que si l'engage dans la télécommande ont été les plus récents puis ils seront fusionnées dans (par défaut, sauf si vous spécifiez --rebase) de votre branche courante.

Comme Ryan a dit, je vous suggère de préciser exactement ce que votre objectif est donc que quelqu'un peut vous aider plus directement.

InformationsquelleAutor Jorge Israel Peña
1

Haut réponse est beaucoup mieux en termes de largeur et de profondeur de l'information, mais il semble comme si vous vouliez que votre problème fixe presque immédiatement, et ne me dérange pas trodding sur certains des principes de base du contrôle de version, vous pouvez ...
1. Commutateur maître
```
$ git checkout upstream master
```
2. Supprimer les indésirables de la branche. (Note: il faut avoir l'-D, au lieu de la normale-d indicateur parce que votre direction est beaucoup s'engage devant le maître.)
```
$ git branch -d <branch_name>
```
3. Créer une nouvelle branche
```
$ git checkout -b <new_branch_name>
```
InformationsquelleAutor BrotherDonkey
0

Aucune de ces réponses a travaillé pour moi, j'ai été en mesure de résoudre le problème à l'aide de la commande suivante.

git fetch origin

Ce fait un truc pour moi.

InformationsquelleAutor Kenny

Vous devez vous connecter pour publier un commentaire.