Comment récupérer les modifications non validées dissimulées

J’ai eu quelques changements non validés dans ma twig de développement et je les ai cachés en utilisant git stash , mais il y avait quelques changements très importants parmi ceux-ci. Est-il possible de récupérer ces changements?

En outre, j’ai apporté quelques modifications aux fichiers de code cachés depuis.

Y a-t-il une chance de pouvoir récupérer les modifications cachées dans une nouvelle twig si possible?

La réponse facile à la question facile est git stash apply

Il suffit de vérifier la twig sur laquelle vous souhaitez que vos modifications git stash apply , puis d’ git stash apply . Utilisez ensuite git diff pour voir le résultat.

Une fois que vous avez terminé avec vos modifications – l’ apply semble bonne et vous êtes sûr de ne plus avoir besoin de la réserve – alors utilisez git stash drop pour vous en débarrasser.

Je suggère toujours d’utiliser git stash apply plutôt que de faire de la git stash pop . La différence réside dans le fait qu’appliquer permet de réessayer facilement l’ apply , ou de regarder, etc. Si la fonction pop peut extraire la réserve, elle la lâchera immédiatement, et si vous réalisez soudain que vous voulez pour l’extraire ailleurs (dans une twig différente), ou avec --index , ou quelque --index genre, ce n’est pas si facile. Si vous apply , vous pouvez choisir quand drop .

Tout est plutôt mineur dans un sens ou dans l’autre, et pour un débutant, cela devrait être à peu près la même chose. (Et vous pouvez sauter tout le rest!)


Et si vous faites des choses plus avancées ou plus compliquées?

Il y a au moins trois ou quatre façons différentes d’utiliser git stash. Ce qui précède est pour “way 1”, “easy way”:

  1. Vous avez commencé avec une twig propre, travailliez sur des modifications, puis vous vous êtes rendu compte que vous les faisiez dans la mauvaise twig. Vous voulez juste prendre les modifications que vous avez maintenant et les “déplacer” vers une autre twig.

    C’est le cas simple, décrit ci-dessus. Exécutez git stash save (ou plain git stash , même chose). Découvrez l’autre twig et utilisez git stash apply . Cela permet à git de fusionner avec vos modifications précédentes, en utilisant le mécanisme de fusion plutôt puissant de git. Inspectez attentivement les résultats (avec git diff ) pour voir si vous les aimez et, si vous les aimez, utilisez git stash drop pour laisser tomber la réserve. Vous avez terminé!

  2. Vous avez commencé des changements et les avez cachés. Ensuite, vous êtes passé à une autre twig et vous avez commencé plus de changements, en oubliant que vous aviez les fichiers stockés.

    Maintenant, vous souhaitez conserver, voire déplacer, ces modifications et appliquer également votre réserve.

    Vous pouvez en fait git stash save nouveau, car git stash crée une “stack” de modifications. Si vous faites cela, vous avez deux caches, l’un juste appelé stash mais vous pouvez également écrire un stash@{0} – et un stash@{1} épelé stash@{1} . Utilisez la git stash list (à tout moment) pour les voir tous. Le plus récent est toujours le plus petit. Lorsque vous git stash drop , celle-ci supprime la plus récente, et celle qui était stash@{1} se déplace en haut de la stack. Si vous en aviez encore plus, celle qui était stash@{2} devient stash@{1} , et ainsi de suite.

    Vous pouvez également apply et drop une réserve spécifique: git stash apply stash@{2} , etc. La suppression d’une réserve spécifique ne renumérote que les numéros les plus élevés. Là encore, celui sans numéro est également stash@{0} .

    Si vous accumulez beaucoup de stashes, cela peut être assez compliqué (est-ce que la réserve que je voulais stash@{7} ou était-elle stash@{4} ? Attendez, j’en viens à une autre, maintenant ils sont 8 et 5?) . Personnellement, je préfère transférer ces modifications vers une nouvelle twig, car les succursales ont des noms, et la cleanup-attempt-in-December signifie beaucoup plus pour moi que les stash@{12} . (La commande git stash prend un message de sauvegarde facultatif, et ceux-ci peuvent aider, mais de toute façon, tous mes stashes se terminent par le nom de WIP on branch .)

  3. (Extra-advanced) Vous avez utilisé git stash save -p , ou soigneusement git add des bits spécifiques de votre code avant d’exécuter git stash save . Vous aviez une version dans la zone d’indexation / mise en attente masquée et une autre version (différente) dans l’arborescence de travail. Vous voulez conserver tout cela. Donc maintenant, vous utilisez git stash apply --index , et cela échoue parfois avec:

     Conflicts in index. Try without --index. 
  4. Vous utilisez git stash save --keep-index pour tester “ce qui sera commis”. Celui-ci dépasse le cadre de cette réponse; voir à la place cette autre réponse StackOverflow .

Pour les cas compliqués, je recommande de commencer par un répertoire de travail “propre”, en validant les modifications que vous avez maintenant (sur une nouvelle twig si vous le souhaitez). De cette façon, le “quelque part” que vous appliquez ne contient rien d’autre, et vous ne ferez que tester les modifications cachées:

 git status # see if there's anything you need to commit # uh oh, there is - let's put it on a new temp branch git checkout -b temp # create new temp branch to save stuff git add ... # add (and/or remove) stuff as needed git commit # save first set of changes 

Maintenant, vous êtes sur un sharepoint départ “propre”. Ou peut-être que ça ressemble plus à ceci:

 git status # see if there's anything you need to commit # status says "nothing to commit" git checkout -b temp # optional: create new branch for "apply" git stash apply # apply stashed changes; see below about --index 

La principale chose à retenir est que le “stash” est un commit, c’est juste un commit légèrement “drôle / bizarre” qui n’est pas “sur une twig”. L’opération apply examine ce que le commit a changé et essaie de le répéter où que vous soyez maintenant. La réserve sera toujours là ( apply ), vous pouvez donc la regarder plus ou décider que ce n’est pas le bon endroit pour l’ apply et réessayer différemment, ou peu importe.


Chaque fois que vous avez une réserve, vous pouvez utiliser git stash show -p pour voir une version simplifiée de ce qui est dans la réserve. (Cette version simplifiée ne prend en compte que les modifications apscopes à l’arbre de travail final, pas les modifications d’index sauvegardées séparément.) La commande git stash apply , sans --index , tente simplement de modifier répertoire maintenant.

Cela est vrai même si vous avez déjà quelques modifications. La commande apply est heureuse d’appliquer un cache à un répertoire de travail modifié (ou du moins, de tenter de l’appliquer). Vous pouvez, par exemple, faire ceci:

 git stash apply stash # apply top of stash stack git stash apply stash@{1} # and mix in next stash stack entry too 

Vous pouvez choisir l’ordre “appliquer” ici, en sélectionnant les caches particulières à appliquer dans une séquence particulière. Notez, cependant, que chaque fois que vous faites essentiellement une “fusion de git” et que la documentation de fusion vous avertit:

Il est déconseillé de lancer la fusion de git avec des modifications non validées non sortingviales: bien que cela soit possible, cela peut vous laisser dans un état difficile à résoudre en cas de conflit.

Si vous commencez avec un répertoire propre et que vous ne faites que plusieurs opérations git apply , il est facile de revenir en arrière: utilisez git reset --hard pour revenir à l’état propre et modifiez vos opérations d’ apply . (C’est pourquoi je recommande de commencer par un répertoire de travail propre pour ces cas compliqués.)


Qu’en est-il du pire cas possible?

Disons que vous faites beaucoup de choses avec Git Stuff, et que vous avez fait une réserve, et que vous voulez git stash apply --index , mais il n’est plus possible d’appliquer le stash enregistré avec --index , car la twig a divergé trop depuis le moment où vous l’avez sauvegardé.

C’est à quoi sert la git stash branch .

Si vous:

  1. vérifiez le commit exact sur lequel vous étiez lorsque vous avez fait la stash originale, puis
  2. créer une nouvelle twig et enfin
  3. git stash apply --index

la tentative de recréer les changements fonctionnera définitivement. C’est ce que fait la git stash branch newbranch . (Et puis il laisse tomber la réserve depuis qu’il a été appliqué avec succès.)


Quelques derniers mots sur --index (qu’est-ce que c’est que ça?)

Ce --index fait --index est simple à expliquer, mais un peu compliqué en interne:

  • Lorsque vous avez des modifications, vous devez les git add (ou les “mettre en scène”) avant de les commit .
  • Ainsi, lorsque vous avez lancé git stash , vous avez peut- être édité les fichiers foo et zorg , mais vous n’avez mis en scène qu’un seul.
  • Donc, quand vous demandez de récupérer le cache, il peut être intéressant de lui git add des éléments add et de ne pas git add les éléments non ajoutés. C’est-à-dire que si vous add ed foo mais pas zorg avant que vous ne le stash , il pourrait être intéressant d’avoir exactement la même configuration. Ce qui était mis en scène, devrait encore être mis en scène; Ce qui a été modifié mais pas mis en scène devrait à nouveau être modifié mais pas mis en scène.

L’indicateur --index à apply essaie de définir les choses de cette façon. Si votre arbre de travail est propre, cela fonctionne généralement. Si votre arbre de travail contient déjà des éléments add , vous pouvez voir qu’il peut y avoir des problèmes ici. Si vous --index , l’opération d’ apply ne tente pas de conserver l’ensemble de l’installation par étapes / non mise en scène. Au lieu de cela, il appelle simplement les machines de fusion de git, en utilisant la validation de l’arborescence dans le “sac de stockage” . Si vous ne vous souciez pas de préserver la mise en scène / non mise en scène, omettre --index rend les choses beaucoup plus faciles pour faire ce que vous voulez.

 git stash pop 

va tout remettre en place

Comme suggéré dans les commentaires, vous pouvez utiliser la git stash branch newbranch pour appliquer le cache à une nouvelle twig, qui est identique à l’exécution:

 git checkout -b newbranch git stash pop 

Pour rendre cela simple, vous avez deux options pour réappliquer votre cachette:

  1. git stash pop – Restaure l’état enregistré, mais supprime le stash du stockage temporaire.
  2. git stash apply : restaure l’état enregistré et quitte la liste de stockage pour une réutilisation éventuelle ultérieure.

Vous pouvez lire plus en détail à propos des stacks git dans cet article.