Quel est le cas d'utilisation prévu pour git stash?


143

Si je travaille sur la branche A et que je dois soudainement travailler sur la branche B avant d'être prêt avec un commit sur la branche A, je cache mes modifications sur A, checkout B, fais mon travail là-bas, puis checkout A et applique le stash.

Si je travaille sur A et que je veux arrêter de travailler pour la journée, dois-je mettre mon travail en cache et l'appliquer le lendemain (lorsque je reprendrai mon travail), ou devrais-je simplement laisser les choses telles quelles, fichiers modifiés non validés dans le directeur de travail? Je ne vois pas pourquoi j'aurais besoin d'utiliser stash dans ce cas, sauf s'il y a un avantage de sécurité.

Aussi, un autre scénario: je travaille à la fois au travail et à la maison. Si je ne suis pas prêt avec un commit lorsque je veux rentrer chez moi, puis-je cacher mon travail, le pousser sur GitHub, puis récupérer ce stock chez moi?


3
dépend largement des politiques de votre entreprise, le cas échéant. Comment choisirez-vous la réponse «acceptée»?
Daemon Painter le

1
Cette question telle qu'elle est formulée ne demande que des opinions (devrais-je utiliser git de cette façon ou de cette façon?) Et doit donc être fermée ou modifiée.
TylerH

Réponses:


162

Stash n'est qu'une méthode pratique. Comme les branches sont si bon marché et faciles à gérer dans git, personnellement, je préfère presque toujours créer une nouvelle branche temporaire plutôt que de la cacher, mais c'est surtout une question de goût.

Le seul endroit où j'aime cacher est si je découvre que j'ai oublié quelque chose dans mon dernier commit et que j'ai déjà commencé à travailler sur le suivant dans la même branche:

# Assume the latest commit was already done
# start working on the next patch, and discovered I was missing something

# stash away the current mess I made
git stash save

# some changes in the working dir

# and now add them to the last commit:
git add -u
git commit --amend

# back to work!
git stash pop

2
La chose que vous avez ajoutée et qui manquait est-elle fusionnée dans la réserve une fois que vous l'avez désinstallée? (Je suis toujours instable sur la façon dont la chronologie fonctionne dans git - je suppose que vous écrasez l'histoire ??)
Kiki Jewell

Les modifications popped @KikiJewell sont appliquées à l'index - elles ne sont pas validées. donc si vous faites git stash popdeux fois, vous perdrez la distinction entre ces deux ensembles de modifications.
Mureinik

À la fin du mois d'octobre 2017, il y a eu une discussion approfondie sur la liste de diffusion Git, dans laquelle la commande git stash save est obsolète au profit de l'alternative existante git stash push. La raison principale en est que git stash pushintroduit l'option de cacher les pathspecs sélectionnés , quelque chose git stash savene prend pas en charge.
Krishna Gupta le

@Mureinik, que pensez-vous des nouvelles branches par rapport à la branche git stash?
Pacerier

@Pacerier comme je l'ai dit dans le premier paragraphe, je préfère presque toujours créer une nouvelle branche, mais c'est probablement plus une force d'habitude qu'un raisonnement technique solide.
Mureinik

41

Je vais casser la réponse sur trois paragraphes.

Partie 1:

git stash(Pour enregistrer vos modifications non validées dans un "stash". Remarque: cela supprime les modifications de l'arborescence de travail!)

git checkout some_branch(changement vers la succursale prévue - dans ce cas some_branch)

git stash list (liste des cachettes)

Vous pouvez voir:
stash @ {0}: WIP sur {branch_name}: {SHA-1 of last commit} {last commit of you branch}
stash @ {0}: WIP sur master: 085b095c6 modification pour test

git stash apply (pour appliquer le stash à l'arbre de travail dans la branche actuelle)

git stash apply stash@{12}(si vous avez beaucoup de stash, vous pouvez choisir quel stash s'appliquera - dans ce cas, nous appliquons le stash 12)

git stash drop stash@{0}(pour supprimer de la liste des réserves - dans ce cas, des réserves 0)

git stash pop stash@{1} (pour appliquer la réserve sélectionnée et la supprimer de la liste des réserves)

Partie 2:
Vous pouvez masquer vos modifications avec cette commande mais ce n'est pas nécessaire.
Vous pouvez continuer le lendemain sans cachette.
Ceci commande pour cacher vos changements et travailler sur différentes branches ou pour implémenter une certaine réalisation de votre code et enregistrer dans des stashes sans branches et commitsor votre cas personnalisé!
Et plus tard, vous pouvez utiliser certains des stashes et vérifier ce qui est le mieux.

Partie 3:
Commande Stash pour masquer localement vos modifications.
Si vous voulez travailler à distance, vous devez vous engager et pousser.


10

L'idée principale est

Rangez les modifications dans un répertoire de travail sale

La commande Basicallly Stash conserve donc vos modifications dont vous n'avez pas besoin ou que vous ne voulez pas pour le moment; mais vous pouvez en avoir besoin.

Utilisez git stash lorsque vous souhaitez enregistrer l' état actuel du répertoire de travail et de l'index, mais que vous voulez retourner dans un répertoire de travail propre. La commande enregistre vos modifications locales et rétablit le répertoire de travail pour qu'il corresponde à la validation HEAD .


8

Vous pouvez utiliser les commandes suivantes:

  • Pour enregistrer vos modifications non validées

    git stash

  • Pour répertorier vos cachettes enregistrées

    git stash list

  • Pour appliquer / récupérer les modifications non validées où x vaut 0,1,2 ...

    git stash apply stash@{x}

Remarque:

  • Pour appliquer une réserve et la supprimer de la liste des réserves

    git stash pop stash@{x}

  • Pour appliquer une réserve et la conserver dans la liste des réserves

    git stash apply stash@{x}


4

Si vous appuyez sur git stashlorsque vous avez des modifications dans la copie de travail (pas dans la zone de préparation), git créera un objet caché et poussera sur la pile de cachettes (comme vous l'avez fait git checkout -- .mais vous ne perdrez pas les modifications). Plus tard, vous pouvez sortir du haut de la pile.


2

La commande stash cachera toutes les modifications que vous avez apportées depuis votre dernier commit. Dans votre cas, il n'y a aucune raison de vous cacher si vous voulez continuer à travailler dessus le lendemain. Je n'utiliserais stash que pour annuler les modifications que vous ne souhaitez pas valider.


2
Non, git stashne changera pas votre succursale. Il ne "rétablira" en particulier aucune modification validée. Il supprimera uniquement (temporairement) toutes les modifications non validées sur vos fichiers. - Cela peut sembler difficile, mais ce genre de mots a une signification très particulière dans le contexte de git. Vous ne devriez vraiment pas les mélanger.
michas

Merci d'avoir fait remarquer cela. J'ai changé ma réponse en conséquence.
Severin

Dans git, une "branche" est définie comme une série de commits. git stashne touchera aucun commit et ne modifiera donc aucune branche du tout. Il ne «supprimera» rien d'une branche et ne le «réinitialisera» d'aucune façon. La branche reste la même, seuls les fichiers de l'arborescence de travail changent. - Ce sont deux choses totalement différentes.
michas

Il ne rejettera pas mais «cachera» vos modifications! Git maintient une structure LIFO pour les cachettes, donc une cachette est en fait une poussée et vous pouvez sortir du haut de celle-ci. Le mot «jeter» signifie que vous perdrez tout, mais vous ne le ferez pas.
gyorgyabraham

2

Je sais que StackOverflow n'est pas l'endroit idéal pour les réponses basées sur les opinions, mais j'ai en fait une bonne opinion sur le moment où mettre les changements dans une réserve.

Vous ne voulez pas vous engager de modifications expérimentales

Lorsque vous apportez des modifications à votre espace de travail / arborescence de travail, si vous devez effectuer des opérations basées sur des branches telles qu'une fusion, une transmission, une extraction ou une extraction, vous devez être à un point de validation propre. Donc, si vous avez des modifications d'espace de travail, vous devez les valider. Mais que faire si vous ne voulez pas les engager? Et s'ils sont expérimentaux? Quelque chose que vous ne voulez pas faire partie de votre historique de commit? Quelque chose que vous ne voulez pas que les autres voient lorsque vous poussez vers GitHub?

Vous ne voulez pas perdre les modifications locales avec une réinitialisation matérielle

Dans ce cas, vous pouvez effectuer une réinitialisation matérielle. Mais si vous effectuez une réinitialisation matérielle, vous perdrez toutes les modifications de votre arbre de travail local car tout est écrasé à l'endroit où il se trouvait au moment du dernier commit et vous perdrez toutes vos modifications.

Donc, en ce qui concerne la réponse `` quand devriez-vous cacher '', la réponse est lorsque vous devez revenir à un point de validation propre avec un arbre de travail / index / commit synchronisé, mais vous ne voulez pas perdre vos modifications locales dans le processus. Mettez simplement vos modifications dans une réserve et vous êtes bon.

Et une fois que vous avez fait votre réserve, puis fusionné, tiré ou poussé, vous pouvez simplement cacher pop ou postuler et vous êtes de retour à votre point de départ.

Git stash et GitHub

GitHub ajoute constamment de nouvelles fonctionnalités, mais à partir de maintenant, il existe maintenant un moyen d'y enregistrer une réserve. Encore une fois, l'idée d'une réserve est qu'elle est locale et privée. Personne d'autre ne peut jeter un œil dans votre réserve sans un accès physique à votre poste de travail. Un peu de la même manière que git reflog est privé avec le git log est public. Ce ne serait probablement pas privé s'il était poussé vers GitHub.

Une astuce pourrait être de faire un diff de votre espace de travail, de vérifier le diff dans votre référentiel git, de le valider puis de le pousser. Ensuite, vous pouvez faire un pull de chez vous, obtenir le diff et le dérouler. Mais c'est une manière assez désordonnée d'atteindre ces résultats.

git diff > git-dif-file.diff

faire sauter la cachette

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.