La réponse facile à la question facile est git stash apply
Vérifiez simplement la branche sur laquelle vous souhaitez que vos modifications soient effectuées, puis git stash apply
. Utilisez ensuite git diff
pour voir le résultat.
Une fois que vous avez terminé vos modifications - l' apply
apparence est bonne et vous êtes sûr que vous n'avez plus besoin de la cachette - puis utilisez git stash drop
pour vous en débarrasser.
Je suggère toujours d'utiliser git stash apply
plutôt que git stash pop
. La différence est que les apply
feuilles autour de la planque pour rejuger facile du apply
ou pour regarder, etc. Si pop
est en mesure d'extraire la planque, il sera immédiatement aussi drop
, et si vous le réalisez soudainement que vous vouliez extraire quelque part d'autre (dans une branche différente), ou avec --index
, ou quelque chose comme ça, ce n'est pas si facile. Si vous apply
, vous pouvez choisir quand drop
.
C'est tout de même assez mineur d'une manière ou d'une autre, et pour un débutant, il devrait être à peu près la même chose. (Et vous pouvez sauter tout le reste!)
Et si vous faites des choses plus avancées ou plus compliquées?
Il existe au moins trois ou quatre "façons différentes d'utiliser git stash", pour ainsi dire. Ce qui précède est pour la "voie 1", la "voie facile":
Vous avez commencé avec une branche propre, travailliez sur certains changements, puis vous avez réalisé que vous les faisiez dans la mauvaise branche. Vous voulez juste prendre les changements que vous avez maintenant et les "déplacer" vers une autre branche.
C'est le cas facile, décrit ci-dessus. Exécutez git stash save
(ou simplement git stash
, la même chose). Découvrez l'autre branche et utilisez git stash apply
. Cela permet à git de fusionner dans vos modifications précédentes, en utilisant le mécanisme de fusion plutôt puissant de git. Inspectez soigneusement les résultats (avec git diff
) pour voir si vous les aimez, et si vous le faites, utilisez git stash drop
pour déposer la réserve. Vous avez terminé!
Vous avez commencé certains changements et les avez cachés. Ensuite, vous êtes passé à une autre branche et avez commencé d'autres changements, oubliant que vous aviez les cachés.
Vous souhaitez maintenant conserver, voire déplacer, ces modifications et appliquer également votre cachette.
Vous pouvez en fait à git stash save
nouveau, car cela git stash
fait une "pile" de changements. Si vous faites cela, vous avez deux cachettes, une juste appelée stash
- mais vous pouvez également écrire stash@{0}
- et une orthographiée stash@{1}
. Utilisez git stash list
(à tout moment) pour les voir tous. Le plus récent est toujours le plus petit. Lorsque vous git stash drop
, il supprime le plus récent et celui qui était stash@{1}
déplacé vers le haut de la pile. Si vous en aviez encore plus, celui qui l'était stash@{2}
devient stash@{1}
, et ainsi de suite.
Vous pouvez aussi apply
, puis drop
une cachette spécifique:, git stash apply stash@{2}
et ainsi de suite. En supprimant une réserve spécifique, vous ne renumérotez que les numéros plus élevés. Encore une fois, celui sans numéro l'est aussi stash@{0}
.
Si vous empilez beaucoup de cachettes, cela peut devenir assez salissant (était-ce la cachette que je voulais stash@{7}
ou était-ce stash@{4}
? Attendez, j'en ai juste poussé une autre, maintenant elles sont 8 et 5?). Personnellement, je préfère transférer ces modifications dans une nouvelle succursale, car les succursales ont des noms et représentent cleanup-attempt-in-December
beaucoup plus pour moi que stash@{12}
. (La git stash
commande prend un message de sauvegarde facultatif, et ceux-ci peuvent aider, mais d'une manière ou d'une autre, toutes mes réserves se terminent par un nom WIP on branch
.)
(Extra-avancé) Vous avez utilisé git stash save -p
, ou soigneusement git add
et / ou git rm
des bits spécifiques de votre code avant de lancer git stash save
. Vous aviez une version dans l'index / zone de stockage caché et une autre version (différente) dans l'arborescence de travail. Vous voulez conserver tout cela. Alors 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 cette autre réponse StackOverflow à la place.
Pour les cas compliqués, je recommande de commencer par un répertoire de travail "propre" en validant toutes les modifications que vous avez maintenant (sur une nouvelle branche si vous le souhaitez). De cette façon, le «quelque part» que vous appliquez ne contient rien d'autre, et vous essayerez simplement les changements cachés:
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
Vous êtes maintenant sur un point de départ "propre". Ou peut-être que cela 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 branche". L' apply
opération examine ce que le commit a changé et essaie de le répéter où que vous soyez. La cachette sera toujours là (la gardera apply
autour), donc vous pouvez la regarder plus, ou décider que ce n'était pas le bon endroit apply
et réessayer différemment, ou autre chose.
Chaque fois que vous avez une cachette, vous pouvez utiliser git stash show -p
pour voir une version simplifiée de ce qu'elle contient. (Cette version simplifiée ne regarde que les modifications de "l'arborescence de travail finale", pas les modifications d'index enregistrées qui sont --index
restaurées séparément.) La commande git stash apply
, sans --index
, essaie maintenant de faire ces mêmes modifications dans votre répertoire de travail maintenant.
Cela est vrai même si vous avez déjà des modifications. La apply
commande est heureuse d'appliquer une cachette à un répertoire de travail modifié (ou au moins, d'essayer 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 ici la commande «appliquer», en sélectionnant des masques particuliers à appliquer dans une séquence particulière. Notez cependant que chaque fois que vous effectuez une "fusion git", et comme la documentation de fusion l'avertit:
L'exécution de git merge avec des modifications non validées non triviales est déconseillée: bien que cela soit possible, cela peut vous laisser dans un état difficile à reculer en cas de conflit.
Si vous commencez avec un répertoire propre et que vous effectuez simplement plusieurs git apply
opérations, il est facile de revenir en arrière: utilisez git reset --hard
pour revenir à l'état propre et modifiez vos apply
opérations. (C'est pourquoi je recommande de commencer par un répertoire de travail propre, pour ces cas compliqués.)
Et le pire cas possible?
Disons que vous faites beaucoup de trucs Git avancés, et que vous avez créé une stash, et que vous le souhaitez git stash apply --index
, mais il n'est plus possible d'appliquer la stash enregistrée avec --index
, car la branche a trop divergé depuis le moment où vous l'avez enregistrée.
C'est pour ça git stash branch
.
Si vous:
- vérifiez le commit exact sur lequel vous étiez lorsque vous avez fait l'original
stash
, puis
- créer une nouvelle branche, et enfin
git stash apply --index
la tentative de recréer les changements sans aucun doute va fonctionner. C'est ce qui fait. (Et il supprime ensuite la réserve car il a été appliqué avec succès.)git stash branch newbranch
Quelques derniers mots sur --index
(de quoi diable s'agit-il?)
Ce que cela --index
fait est simple à expliquer, mais un peu compliqué en interne:
- Lorsque vous avez des modifications, vous devez
git add
(ou les "mettre en scène") avant de les commit
ing.
- Ainsi, lorsque vous avez exécuté
git stash
, vous avez peut- être édité les deux fichiers foo
et zorg
, mais n'en avez créé qu'un seul.
- Donc, lorsque vous demandez à récupérer la cachette, ce serait bien si ce
git add
sont les add
choses éditées et non git add
les choses non ajoutées. Autrement dit, si vous avez add
édité foo
mais pas zorg
avant de faire le stash
, il serait peut-être bien d'avoir exactement la même configuration. Ce qui a été mis en scène, devrait à nouveau ê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.
Le --index
drapeau pour apply
tente de configurer les choses de cette façon. Si votre arbre de travail est propre, cela fonctionne généralement bien. Si votre arbre de travail contient déjà des éléments add
, vous pouvez voir comment il peut y avoir des problèmes ici. Si vous omettez --index
cette apply
opération , l' opération n'essaie pas de conserver l'intégralité de la configuration par étapes / non. Au lieu de cela, il appelle simplement la machine de fusion de git, en utilisant la validation de l'arbre de travail dans le "sac de dissimulation" . Si vous ne vous souciez pas de la préservation par étapes / sans mise en scène, laisser de côté --index
facilite beaucoup la tâche git stash apply
.