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?
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!)
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”:
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é!
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
.)
(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.
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.)
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:
stash
originale, puis 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.)
--index
(qu’est-ce que c’est que ça?) Ce --index
fait --index
est simple à expliquer, mais un peu compliqué en interne:
git add
(ou les “mettre en scène”) avant de les commit
. git stash
, vous avez peut- être édité les fichiers foo
et zorg
, mais vous n’avez mis en scène qu’un seul. 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:
git stash pop
– Restaure l’état enregistré, mais supprime le stash du stockage temporaire. 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.