Git Sourcetree Master 2 derrière

Question

Je travaille toujours avec Git et Sourcetree et j'ai de la difficulté à comprendre comment ma branche Master se trouve 2 derrière ma branche actuelle qui prétend être la branche maîtresse.

Lorsque j'essaie de fusionner le master dans ma branche actuelle, il indique qu'il est uptodate.

Quelqu'un peut-il me expliquer comment je suis arrivé dans cette situation et mieux encore, comment je peux obtenir maître à jour et le travail de celui-ci?

Merci

EDIT: Alors j'ai fait comme demandé ci-dessous, Commander la branche principale et tiré et qui semble avoir obtenu le mettre à jour, sauf pour les derniers commits semblent avoir disparu. Quelqu'un sait-il pourquoi?

Answer 1

Cela signifie que master est 2 commits derrière origin/master. Vous voyez que origin/master est sur un commit de fusion qui est venu après votre validation master; C'est l'un des deux. L'autre est sur "l'autre côté" de la fusion ("Configurer les bundles ...").

Comment vous êtes arrivé ici, quelqu'un d'autre a poussé les changements à master (sous la forme de fusionner dans une autre branche). Vous avez récupéré les modifications de origin - à quel point votre référence de succursale locale origin/master a été mise à jour - mais vous ne les avez pas encore fusionnées (ou extraites) en master.

Vous pouvez mettre à jour master en vérifiant master et en fusionnant avec origin/master (pas master); ou en effectuant un pull en mode maître (en supposant que le suivi soit configuré de la manière attendue, ce qui est probablement le cas puisque vous obtenez le message "2 behind" attendu). Il y a d'autres moyens, mais ce sont ceux qui ont le plus de sens pour cette situation.

MISE À JOUR

Il semble quand vous avez fait cela, certains commits semblaient disparaître de l'écran. Cela signifie probablement que votre affichage est configuré pour afficher l'historique de ce qui est actuellement extrait. (Ceci est la valeur par défaut pour exécuter git log; Je ne suis pas sûr de savoir comment SourceTree détermine ce que vous voulez afficher, car j'utilise presque exclusivement la ligne de commande.) Il semble y avoir un contrôle déroulant au-dessus de la liste de pourrait contrôler ce qui est affiché.)

Maintenant, vous voulez être un peu prudent, parce que je vois que vous avez maintenant des «changements non validés». Contrairement commits (qui sont assez difficiles à perdre), git ne fait rien pour vous protéger de perdre ces changements non validés. Donc avant de faire d'autres vérifications, vous devez être sûr de savoir quels sont ces changements et s'ils doivent être conservés. Si elles devraient l'être, vous devriez soit les commettre ou les stocker avant de faire d'autres vérifications. (Sur la ligne de commande, git résisterait à un checkout qui perdrait ces changements, mais je ne peux pas parler de ce que SourceTree va faire.)

Quoi qu'il en soit, des commits comme "Fixing Log Out Bug" semblent avoir été créé sur une autre branche; Si vous vérifiez cette branche, vous devriez voir ces commits. Ou si vous modifiez vos paramètres d'affichage pour montrer cette branche (ou --all) vous devriez être capable de les voir.

Vous pouvez voir l'historique de ce que vous avez extrait avec les reflogs. Vraisemblablement, la 3ème entrée dans la refonte principale serait ce que vous avez vérifié lors de la création de la première capture d'écran de la question (sauf si vous avez fait d'autres caisses (ou opérations similaires) en plus de celles que je connais).