Git stash pop : préservez votre travail en changeant de branche

Si vous avez un travail à moitié terminé qui n'est pas prêt à être commit, mais que vous devez changer de contexte immédiatement, ne faites pas de commit "WIP". Et n'allez pas non plus copier-coller vos changements dans un fichier texte comme en 2005. git stash suffit amplement.

Cette commande est la solution réflexe pour sauvegarder du travail non validé tout en changeant de contexte. Elle vous permet de stocker temporairement vos modifications, de gérer des tâches urgentes sur d'autres branches, puis de tout restaurer exactement là où vous vous étiez arrêté.

Dans cet article, je vous explique le fonctionnement de git stash pop, quand le préférer à git stash apply, et comment s'en sortir quand des conflits finissent inévitablement par apparaître.

Si vous débutez avec Git et que la notion de stash vous semble floue, commencez par maîtriser les fondamentaux. Nos cours Introduction to Git et Introduction to GitHub vous mettront sur les rails en un rien de temps.

Comprendre Git stash

Git stash est un espace de stockage temporaire pour vos modifications non validées.

Voyez-le comme un presse-papiers pour votre travail. Vous avez des changements dans votre répertoire de travail qui ne sont pas prêts à être committés, mais vous devez changer de branche ou récupérer des mises à jour du distant. Plutôt que de perdre votre travail ou de faire un commit WIP, vous le mettez en stash.

La commande enregistre vos modifications et remet votre répertoire de travail dans l'état du commit HEAD.

L'idée derrière le stash dans Git

Le stash résout un problème simple : Git ne vous laisse pas changer de branche avec des modifications non validées.

Supposons que vous travailliez sur une fonctionnalité quand un bug est signalé. Vous devez passer tout de suite sur une autre branche, mais vous avez du code à moitié écrit et des fichiers modifiés. Faire un commit n'a pas de sens car votre travail est incomplet. Un checkout forcé ferait disparaître vos changements.

C'est là que le stash intervient.

Voici les scénarios les plus courants où le stash vous aide :

1. Changer de branche pour une urgence : vous êtes en plein développement quand il faut corriger un bug en production.
2. Récupérer des changements distants : un collègue a poussé des mises à jour et vous devez pull, mais vous avez des modifications locales.
3. Éviter des commits brouillons : vous n'êtes pas prêt à commit, mais vous avez besoin d'un espace de travail propre pour un rebase ou un merge.
4. Sauvegarder du code expérimental : vous voulez tenter une autre approche sans perdre votre travail actuel

Le stash est rapide et réversible : pas besoin de réfléchir à un message de commit ou à un nom de branche.

L'architecture de la pile de stashes

Git conserve les stashes dans une pile LIFO (last-in, first-out) : dernier entré, premier sorti.

Chaque fois que vous stashez, Git crée une nouvelle entrée en haut de la pile. Le stash le plus récent devient stash@{0}, et les plus anciens décalent : stash@{1}, stash@{2}, etc.

Sous le capot, chaque stash est en réalité un commit — ou plus précisément, un ensemble de commits. Git crée une structure de commit à plusieurs parents qui stocke :

1. Vos changements dans le répertoire de travail
2. Vos changements indexés (l'index)
3. Les fichiers non suivis (si vous avez utilisé l'option u)

Conséquence : les stashes ne sont pas de simples instantanés. Ce sont de vrais commits que Git peut fusionner à nouveau dans votre répertoire de travail plus tard.

Vous pouvez référencer les stashes de deux façons : par index avec la syntaxe stash@{0}, ou via git stash list pour retrouver le message associé et cibler un stash précis. L'index est plus rapide pour les stashes récents, mais les messages sont plus utiles quand la pile s'allonge.

Voici à quoi ressemble une pile de stashes typique :

Le préfixe WIP on signifie que vous avez utilisé git stash sans message. Le préfixe On indique que vous avez fourni un message personnalisé avec git stash push -m.

Les stashes ne vivent que dans votre dépôt local : ils ne sont jamais poussés vers le distant. Votre travail temporaire reste donc là où il doit être : sur votre machine, prêt à être restauré quand vous en avez besoin.

Créer, gérer et examiner des stashes

La commande git stash de base suffit pour commencer, mais elle est sommaire. Vous vous retrouvez avec une pile d'entrées "WIP on branch-name" qui ne disent rien de concret. Six semaines plus tard, impossible de savoir quel stash contient la correction de bug et lequel renferme votre refactorisation inachevée.

Voici comment bien faire dès le départ.

Créer des stashes avec un bon méta-détail

La façon la plus simple de stasher est de taper git stash :

git stashPropulsé par

Cela enregistre vos changements, mais le message "WIP on main" n'est pas très parlant. Impossible de savoir ce qu'il contient sans l'inspecter.

Préférez git stash push -m avec un message descriptif :

git stash push -m "Updated file.txt"Propulsé par

Votre liste de stashes devient vraiment utile :

La différence saute aux yeux. Une entrée vous dit exactement ce que vous avez fait, l'autre vous laisse deviner.

Rédigez les messages comme si vous écriviez à votre futur vous. "Ajout de la logique d'auth", "Correction du bug de la navbar" ou "Expérimentation d'un nouveau design d'API" sont bien plus utiles que des WIP génériques.

Inclure des fichiers non suivis ou ignorés

Par défaut, git stash n'enregistre que les fichiers suivis — ceux que Git connaît déjà.

Les fichiers non suivis restent dans votre répertoire de travail. Beaucoup sont surpris de les voir encore présents après un stash et un changement de branche.

Voici ce qui se passe :

echo "new_feature.py" > new_feature.py
git stashPropulsé par

Le fichier n'a pas été stashé car Git ne le suit pas encore :

Pour contourner cela, utilisez l'option -u afin d'inclure les fichiers non suivis :

git stash push -u -m "Added a Python file for a new cool feature"Propulsé par

Cela stashe à la fois les fichiers suivis et non suivis. Votre répertoire de travail redevient totalement propre.

Astuce : vous pouvez ajouter l'option -a pour inclure aussi les fichiers ignorés. Elle stashe les fichiers suivis, les non suivis et ceux présents dans votre .gitignore. Vous en aurez rarement besoin, sauf pour déboguer des problèmes de build ou sauvegarder un instantané parfaitement propre de tout.

Voici un pense-bête pour savoir quand utiliser chaque option :

1. Sans option : vous n'avez modifié que des fichiers existants

2. u (option) : vous avez ajouté des fichiers que Git ne suit pas encore

3. a (option) : vous devez tout sauvegarder, y compris les sorties de build et les fichiers temporaires

La plupart du temps, vous utiliserez -u. C'est l'option la plus sûre quand vous avez créé de nouveaux fichiers pendant le développement.

Stash partiel ou sélectif

Vous n'êtes pas obligé de stasher tout votre répertoire de travail.

Disons que vous avez corrigé deux bugs, mais vous ne voulez en stasher qu'un. Ou que vous avez des changements dans cinq fichiers, mais seuls trois concernent la fonctionnalité à sauvegarder.

Vous pouvez stasher des fichiers précis avec un pathspec :

git stash push -m "New files" new_file.txt new_file_2.txtPropulsé par

Cela ne stashe que new_file.txt et new_file_2.txt. Le reste reste dans votre répertoire de travail.

Vous pouvez aussi utiliser des jokers :

git stash push -m "Stash all txt files" *.txtPropulsé par

Ou utiliser --patch pour un stash interactif :

git stash push --patchPropulsé par

Git passe en revue chaque changement et vous demande si vous voulez le stasher. Vous répondez y (oui), n (non), ou s (scinder ce hunk en morceaux plus petits).

Pratique quand des changements liés et non liés cohabitent dans le même fichier. Vous stasherez la partie fonctionnelle et laisserez le code de debug.

Voici à quoi ressemble l'invite interactive :

Lister et examiner les stashes

Comme vous l'avez vu, vous pouvez exécuter git stash list pour afficher tout ce que vous avez stashé :

Le stash le plus récent est toujours stash@{0}. Les plus anciens descendent dans l'index.

Si vous avez écrit de bons messages, vous parcourrez la liste en sachant exactement ce que contient chaque stash. Sinon, il faudra les inspecter un par un.

Utilisez git stash show pour un résumé :

Vous voyez quels fichiers ont changé et combien de lignes ont été ajoutées ou supprimées.

Vous pouvez aussi utiliser git stash show -p pour voir la différence complète :

L'option -p affiche les changements de code exacts, comme git diff. Idéal pour confirmer que vous allez pop le bon stash avant d'exécuter git stash pop.

Ce que fait vraiment Git stash pop

Passons à git stash pop — ce que la commande fait concrètement et pourquoi l'utiliser.

Comportement fondamental et syntaxe

La commande git stash pop fait deux choses : elle applique votre stash puis supprime ce stash de la pile.

Voici la syntaxe de base :

git stash popPropulsé par

Cela pop le stash le plus récent (stash@{0}) et le retire de la liste.

Vous pouvez aussi pop un stash spécifique en référençant son index :

git stash pop stash@{1}Propulsé par

Cela applique stash@{1} et le supprime. Mais attention : les indices restants se décalent vers le haut. Ce qui était stash@{2} devient stash@{1}, et ainsi de suite.

Comment Git traite un stash pop

Lorsque vous lancez git stash pop, Git effectue en coulisse une fusion à trois voies.

Il compare trois états :

1. Le commit de base (là où vous avez créé le stash)
2. Votre commit HEAD actuel
3. Les modifications stashées

Si la fusion réussit sans conflit, Git applique vos changements et supprime le stash. Votre répertoire de travail redevient exactement comme avant le stash.

Exemple de workflow simple :

# Vous travaillez sur une fonctionnalité
echo "new feature code" >> feature.py
git stash push -m "Half-finished feature work"

# Basculez sur une nouvelle branche et faites des changements sans lien
git checkout bugfix
echo "bug fix" >> bugfix.py
git add bugfix.py
git commit -m "Fix critical bug"

# Retournez sur l'autre branche
git checkout main

# Restaurez votre travail stashé
git stash popPropulsé par

Si Git ne peut pas fusionner proprement, vous obtenez un conflit. Le stash reste dans votre pile car le pop n'a pas abouti. Vous verrez des marqueurs de conflit dans vos fichiers, comme lors d'une fusion classique.

En cas de conflits, il faut les résoudre manuellement, indexer les fichiers corrigés, puis commit. Le stash ne disparaît pas automatiquement : vous devrez exécuter git stash drop après avoir tout résolu.

Appliquer des stashes entre les branches

Les stashes ne sont liés à aucune branche en particulier.

Vous pouvez créer un stash sur bugfix, passer sur main, et pop ce stash là. Git ne se soucie pas de son origine : il tente simplement d'appliquer les changements sur la branche courante.

Cela ouvre des workflows pratiques :

1. Déplacer du travail entre branches : vous avez commencé au mauvais endroit. Plutôt que de reset et perdre du travail, vous le stashé, changez de branche et le poppez là.

2. Réorganiser des tâches : vous avez stashé du code expérimental il y a une semaine. Vous voulez maintenant l'essayer sur une autre branche pour voir s'il s'intègre mieux.

3. Tester des changements dans différents contextes : vous avez une correction de bug en stash et souhaitez la tester sur plusieurs branches avant de commit. Utilisez git stash apply plutôt que pop pour garder le stash, tester, puis le pop sur la branche où vous validerez. Nous revenons sur apply dans un instant.

Tant que les changements ne sont pas en conflit avec votre branche actuelle, le stash s'applique proprement : c'est l'idée à retenir.

Git stash pop vs git stash apply

Beaucoup de développeurs hésitent entre git stash pop et git stash apply.

La différence clé : la persistance du stash

La principale différence est simple : pop supprime le stash après l'avoir appliqué, tandis que apply le conserve dans la pile.

Avec pop, vous dites : "J'en ai fini avec ce stash : applique-le et jette-le". Avec apply, vous dites : "Je pourrais en avoir encore besoin".

Conséquences sur votre flux de travail :

1. Sécurité : si quelque chose se passe mal avec un pop et que vous devez récupérer, le stash a pu être supprimé. Avec apply, le stash reste comme filet de sécurité.

2. Nettoyage : utiliser pop maintient automatiquement la pile propre. Avec apply, il faut exécuter git stash drop manuellement ensuite pour supprimer les stashes terminés.

La plupart des développeurs utilisent par défaut pop car c'est plus propre. Mais apply est préférable si vous n'êtes pas sûr que le stash s'appliquera proprement sur la branche courante, ou si vous voulez tester les mêmes changements sur plusieurs branches.

Prévisibilité, risque et décalage des index

Là où pop se complique, c'est que les indices se décalent quand vous poppez au milieu de la pile.

Supposons que vous ayez trois stashes :

stash@{0}: Feature work
stash@{1}: Bug fix
stash@{2}: Experimental codePropulsé par

Si vous poppez stash@{1}, les stashes restants montent d'un cran :

stash@{0}: Feature work
stash@{1}: Experimental codePropulsé par

Cela peut poser problème si vous scriptéz des opérations Git ou enchaînez plusieurs pop. Vous poppez stash@{1}, puis tentez de popper stash@{2}, mais cet index n'existe plus.

La commande apply n'a pas ce souci. Les indices ne changent que si vous lancez explicitement git stash drop. Vous pouvez appliquer des stashes dans n'importe quel ordre sans crainte que la pile bouge en cours de route.

Gestion des conflits identique

Les deux commandes gèrent les conflits de manière identique.

Si Git ne peut pas fusionner proprement, vous verrez des marqueurs de conflit. La différence concerne le sort du stash :

1. Avec pop : le stash reste dans la pile car le pop a échoué

2. Avec apply : le stash reste dans la pile (ce qui serait le cas de toute façon)

Dans les deux cas, vous devez résoudre les conflits à la main, indexer les fichiers résolus avec git add, et supprimer le stash avec git stash drop (si vous utilisiez apply).

Le processus de résolution est identique : seule change la suppression automatique (ou non) du stash en cas de succès.

Quand choisir l'un ou l'autre

Utilisez git stash pop lorsque :

1. Vous appliquez un stash une seule fois et vous n'en aurez plus besoin
2. Vous souhaitez garder votre pile propre automatiquement
3. Vous travaillez sur une seule branche et n'avez pas besoin du stash ailleurs

Utilisez git stash apply lorsque :

1. Vous voulez tester les mêmes changements sur plusieurs branches
2. Vous n'êtes pas certain que le stash s'appliquera proprement
3. Vous scriptéz des opérations Git et avez besoin d'indices prévisibles
4. Vous voulez un filet de sécurité en cas de souci

Gérer les conflits lors d'un stash pop

Les conflits surviennent quand Git ne peut pas fusionner proprement vos changements stashés. Voici comment les gérer.

Pourquoi et quand les conflits surviennent

Un conflit apparaît durant la fusion à trois voies exécutée lors du pop d'un stash.

Git compare trois versions de votre code :

1. Le commit de base où vous avez créé le stash
2. Votre commit HEAD actuel
3. Les changements du stash

Si les mêmes lignes ont été modifiées à la fois dans votre branche actuelle et dans le stash, Git ne sait pas quelle version garder. C'est un conflit.

Causes fréquentes des conflits avec un stash pop :

1. Vous avez modifié le même fichier sur les deux branches : vous avez stashé des changements, changé de branche, puis édité à nouveau le même fichier avant de pop.
2. Quelqu'un a poussé des changements : vous avez stashé, puis pull, et ces mises à jour touchent le même code.
3. Vous avez fait un rebase ou un cherry-pick : le commit de base attendu par Git n'existe plus, ce qui génère des incohérences de fusion.

En résumé, plus un stash reste longtemps en attente, plus le risque de conflits à l'application augmente.

Workflow de résolution de conflits

En cas de conflit, Git interrompt le pop et marque les fichiers en conflit :

Votre fichier contient désormais des marqueurs de conflit :

Tout ce qui se trouve entre <<<<<<< Updated upstream et ======= est votre code actuel. Tout ce qui se trouve entre ======= et >>>>>>> Stashed changes provient du stash.

Procédez ainsi pour corriger :

1. Ouvrez le fichier en conflit et choisissez quelle version garder (ou fusionnez-les)

2. Supprimez les marqueurs de conflit (<<<<<<<, =======, >>>>>>>)

3. Indexez le fichier résolu avec git add

4. Supprimez le stash manuellement avec git stash drop — il ne disparaîtra pas tout seul.

Stratégies alternatives

Si vous préférez éviter les conflits sur votre branche actuelle, utilisez git stash branch.

Cette commande crée une nouvelle branche à partir du commit où vous avez fait le stash, puis y applique le stash :

git stash branch temp-featurePropulsé par

Git crée une branche appelée temp-feature, la checkout, et y pop votre stash. Comme la branche part exactement du commit où vous avez stashé, il n'y aura pas de conflits. Je détaillerai ce point dans une autre section.

Vous pouvez aussi annuler un pop échoué avec git reset --merge :

git stash pop

# Des conflits apparaissent

git reset --mergePropulsé par

Cela annule la tentative et remet votre répertoire de travail dans l'état antérieur. Le stash reste dans la pile.

Annuler une opération de stash en cours

Si vous avez lancé un pop ou un apply et voulez tout annuler, vous avez des options.

Pour des conflits que vous n'avez pas commencé à résoudre, exécutez :

git reset --mergePropulsé par

Cela annule la fusion et nettoie votre répertoire de travail. Tout revient à l'état précédent.

Pour des conflits partiellement résolus, exécutez :

git reset --hard HEADPropulsé par

Cette commande jette toutes les modifications de votre répertoire de travail, y compris vos résolutions partielles. Utilisez-la si vous avez fait un micmac et voulez repartir de zéro.

N'oubliez pas qu'elle détruit le travail non validé. Assurez-vous de vouloir tout abandonner avant de l'exécuter.

Après annulation, votre stash est toujours dans la pile (sauf si pop a réussi avant l'apparition des conflits). Vous pourrez réessayer plus tard ou utiliser git stash branch pour une approche plus propre.

Nettoyer ses stashes

Les stashes s'accumulent vite sur des projets de longue durée. Vous stashé pour corriger un bug, puis vous oubliez. Vous créez des stashes expérimentaux que vous ne poppez jamais. Six mois plus tard, vous en avez 20 et ignorez la moitié de leur contenu.

Résultat : retrouver le bon stash devient fastidieux. Vous finissez par exécuter git stash show -p sur chacun juste pour savoir ce qu'il contient.

C'est une vraie perte de temps : pensez à faire le ménage régulièrement.

Supprimer des stashes individuels

Utilisez git stash drop pour retirer un stash précis :

git stash drop stash@{2}Propulsé par

Cela supprime stash@{2} de votre pile. Les stashes restants montent d'un cran : stash@{3} devient stash@{2}.

Vous pouvez aussi supprimer le dernier stash sans préciser d'index :

git stash dropPropulsé par

Cela supprime stash@{0} par défaut.

D'après mon expérience, je supprime un stash surtout quand :

1. Vous réalisez que vous n'avez plus besoin des changements
2. Vous avez des doublons (plus fréquent qu'on ne le pense)
3. Un stash est si ancien que vous ne savez plus à quoi il servait

En cas de doute, inspectez avec git stash show -p. Mieux vaut prévenir que guérir.

Vider toute la pile de stashes

Vous pouvez utiliser git stash clear pour tout supprimer d'un coup :

git stash clearPropulsé par

Gardez en tête que c'est définitif. Impossible d'annuler ou de récupérer ensuite.

N'utilisez git stash clear que si vous êtes absolument certain de ne rien vouloir conserver.

Le plus souvent, mieux vaut supprimer au cas par cas pour éviter d'effacer quelque chose d'utile par erreur.

Créer des branches à partir de stashes

Parfois, la solution la plus propre est de transformer un stash en branche dédiée. Vous évitez ainsi les conflits et donnez un vrai cadre à votre travail stashé.

Utiliser git stash branch

La commande git stash branch crée une nouvelle branche et y applique votre stash :

Voici ce qui se passe :

1. Git crée une branche feature-experiment à partir du commit où vous avez fait le stash

2. Git checkout cette nouvelle branche

3. Git pop le stash sur cette branche

4. Git retire le stash de votre pile (comme avec pop)

Comme la branche démarre exactement du même commit que le stash, il n'y aura aucun conflit. L'application est propre à chaque fois.

Vous pouvez également cibler un stash spécifique plutôt que le plus récent :

git stash branch new-feature stash@{2}Propulsé par

Cas d'usage courants

Transformer un stash en branche est idéal pour les fonctionnalités expérimentales. Disons que vous avez stashé du code d'essai il y a une semaine et que vous souhaitez maintenant le développer proprement, sans perturber votre travail en cours.

Vous obtenez une branche propre pour mener l'expérimentation. Si ça fonctionne, vous fusionnez. Sinon, vous supprimez la branche et passez à autre chose.

C'est aussi très utile pour de longs rebase. Plutôt que de gérer des conflits potentiels pendant le rebase, stashé tout et créez une branche à partir du stash.

git stash push -m "WIP before rebase"
git rebase main
git stash branch temp-workPropulsé par

Vous pouvez alors revoir séparément les changements stashés et décider comment les intégrer après le rebase.

Créer une branche est aussi pratique pour isoler des changements volumineux ou désordonnés. Imaginez un stash massif touchant 15 fichiers, dont la moitié en conflit avec votre branche : créez une nouvelle branche et épargnez-vous la bataille.

Vous disposez d'un espace dédié pour tout passer en revue sereinement, faire des commits propres, puis fusionner avec un historique clair.

Techniques avancées et options de récupération

Vous connaissez désormais les bases de git stash, passons à des notions plus avancées.

Travailler avec des entrées de stash spécifiques

Vous pouvez pop ou apply n'importe quel stash de la pile, pas seulement le plus récent.

Référencez-les par index pour récupérer exactement ce qu'il vous faut :

git stash pop stash@{3}
git stash apply stash@{1}Propulsé par

Vous pouvez ainsi récupérer d'anciens stashes sans toucher aux plus récents. Lorsque vous poppez un stash intermédiaire, tous les indices au-dessous se décalent. Ce qui était stash@{4} devient stash@{3}, etc. Si vous scriptéz Git ou enchaînez des pops, ce décalage cassera vos commandes.

La parade consiste à utiliser apply à la place de pop quand vous avez besoin d'indices stables :

git stash apply stash@{2}

# Supprimez-le manuellement quand vous avez fini
git stash drop stash@{2}Propulsé par

Vous gardez ainsi la main sur l'ordre des changements de pile. Vous appliquez, vous vérifiez, puis vous droppez vous-même. Les indices ne bougent que lorsque vous le demandez.

Restaurer l'état de l'index

Par défaut, git stash pop et git stash apply restaurent vos changements mais pas l'état de l'index.

Imaginons trois fichiers modifiés, dont deux étaient indexés avant le stash. Au pop, les trois reviennent en modifications non indexées. Git perd l'information de ce que vous vouliez committer.

La solution : utiliser l'option --index pour restaurer exactement l'état de staging :

git stash pop --indexPropulsé par

Votre arbre de travail et l'index sont recréés à l'identique. Les fichiers qui étaient indexés le restent, les autres non.

Utile lorsque :

1. Vous préparez un commit soigneusement sélectionné et ne pouvez pas perdre cet état

2. Vous travaillez avec des mises en index complexes, par exemple après un git add -p sur certains hunks

3. Vous voulez retrouver à l'identique l'état pré-stash, sans exception

Le plus souvent, vous n'en aurez pas besoin : vous poppez, regardez, puis indexez ce qu'il faut.

Récupérer après une erreur de stash

Il vous arrivera de supprimer un stash utile ou de vider la pile par erreur.

Dans ce cas, le reflog de Git peut vous sauver la mise.

Le reflog trace chaque modification de référence du dépôt, y compris les stashes. Lors de la création ou suppression d'un stash, Git l'enregistre dans le reflog. Même après suppression, les commits existent encore un temps comme objets inaccessibles.

Vous pouvez retrouver votre stash perdu en cherchant les commits inaccessibles :

git fsck --unreachable | grep commitPropulsé par

Inspectez ensuite chaque commit :

git show 066ded985342e585bc8e75c074add99ec1950f50Propulsé par

Regardez la diff et le message pour identifier votre stash perdu. Une fois trouvé, rétablissez-le :

git stash apply 066ded985342e585bc8e75c074add99ec1950f50Propulsé par

Cela applique le stash perdu à votre répertoire de travail comme s'il n'avait jamais été supprimé.

Mieux encore, évitez les erreurs en suivant ces bonnes pratiques :

1. Écrivez des messages de stash descriptifs pour savoir exactement ce que vous supprimez. "Corriger le bug de connexion" est plus clair que "WIP" devant une liste de cinq stashes.

2. Utilisez git stash show -p avant de supprimer pour confirmer qu'il s'agit du bon stash. Cinq secondes de vérification évitent cinq minutes de récupération.

3. Nettoyez régulièrement votre pile pour éviter le bazar. Trois stashes utiles sont plus gérables que quinze entrées anciennes.

4. Préférez apply à pop si vous n'êtes pas 100 % sûr de vouloir supprimer le stash. Vous pourrez toujours le dropper plus tard après vérification.

La récupération via le reflog fonctionne, mais elle est fastidieuse. L'image ci-dessus montre déjà combien de commits il faudrait inspecter à la main — et ce n'est qu'un petit projet, créé pour cet article.

Bonnes pratiques et recommandations de workflow

Bien utiliser les stashes, c'est adopter des habitudes qui évitent les erreurs et gardent un flux de travail net. Voici mon approche de référence.

Patrons de workflow recommandés

Le flux le plus sûr tient en peu d'étapes : stash avec message, changement de contexte, puis pop quand vous reprenez.

# Travailler sur feature-branch
git stash push -m "Feature work in progress"

git checkout main
# Gérer l'urgence sur main

# Revenir
git checkout feature-branch
git stash popPropulsé par

Ce schéma couvre la plupart des cas. Vous préservez votre travail, gérez l'interruption, puis restaurez proprement.

Autre schéma fréquent : "inspecter avant de popper". Vous listez, examinez, puis poppez le bon stash.

git stash list
git stash show -p stash@{1}
git stash pop stash@{1}Propulsé par

Cette vérification évite d'appliquer le mauvais stash ou un travail périmé.

Certains préfèrent l'alternative du "commit à regret" plutôt que le stash. Au lieu de stasher, ils font un commit temporaire du type "WIP - not ready", puis l'amendent ou le réinitialisent plus tard. Cela fonctionne si vous n'êtes pas à l'aise avec les stashes ou si vous tenez à garder une trace dans l'historique. L'inconvénient, c'est le risque d'un historique brouillon si vous oubliez de le nettoyer.

Intégration avec les outils de développement

La plupart des interfaces graphiques Git affichent vos stashes et permettent de les pop/apply en un clic.

Des outils comme GitKraken, Sourcetree et GitHub Desktop listent vos stashes dans une barre latérale. Vous voyez le message, inspectez la diff, et appliquez ou supprimez sans taper de commande. Idéal pour comparer plusieurs stashes côte à côté.

L'extension Git de VS Code affiche les stashes dans le panneau de contrôle de source. Un clic droit suffit pour pop, apply ou drop sans quitter l'éditeur.

Les alias shell accélèrent le stash si vous préférez la ligne de commande. Ajoutez ceux-ci à votre .bashrc ou .zshrc :

alias gst='git stash'
alias gstp='git stash pop'
alias gstl='git stash list'
alias gsts='git stash show -p'Propulsé par

Désormais, gst crée un stash, gstp le pop, gstl liste vos stashes, et gsts montre la diff. Quelques frappes gagnées à chaque fois.

Hygiène du stash et travail en équipe

Les stashes sont locaux à votre machine — ils ne sont jamais poussés sur les dépôts distants.

Vos collègues ne les verront pas, et vous ne pourrez pas y accéder depuis un autre ordinateur. Si vous devez partager un travail en cours, ne le stashé pas. Utilisez des patchs ou des branches temporaires.

Pour partager via un patch, exécutez :

git stash show -p > my-work.patch
# Envoyez le fichier à votre collègue
# Il l'appliquera avec : git apply my-work.patchPropulsé par

Envoyez ensuite le fichier de patch à votre collègue ; il l'appliquera via git apply my-work.patch.

Pour partager via une branche temporaire :

git checkout -b temp/work-in-progress
git add .
git commit -m "WIP - authentication feature"
git push origin temp/work-in-progressPropulsé par

Votre collègue peut récupérer la branche, revoir le travail et poursuivre.

Quelle que soit votre approche, gardez une bonne hygiène de stash pour éviter la confusion et garder une pile gérable. Voici quelques bonnes pratiques :

1. Donnez un nom descriptif à chaque stash. "Ajout de la logique d'authentification" indique le contenu. "WIP on feature-branch" ne dit rien.

2. Nettoyez vos stashes chaque semaine. Exécutez git stash list et supprimez tout ce qui a plus d'une semaine. Si vous n'en avez pas eu besoin en sept jours, vous n'en aurez sans doute plus besoin.

3. Ne laissez pas votre pile dépasser cinq stashes. Au-delà, vous transformez le stash en stockage long terme. Poppez, committez, ou supprimez.

4. En équipe, si l'on vous demande : "Où en est le code ?", ne répondez jamais : "Dans mon stash". Les stashes sont privés et temporaires — pas un moyen de partager ou d'archiver du travail important.

Conclusion

Vous savez maintenant comment fonctionne git stash pop et quand l'utiliser.

Au fond, le stash est simple : sauvegarder votre travail non validé, changer de contexte, et le restaurer plus tard. Mais les détails comptent. Savoir quand utiliser pop ou apply, comment gérer les conflits et quand créer des branches depuis un stash vous épargnera bien des heures de frustration.

L'essentiel : le stash est un stockage temporaire, pas une sauvegarde permanente. Rédigez des messages explicites, faites le ménage régulièrement, et ne laissez pas la pile dépasser cinq entrées. Pour partager ou conserver sur le long terme, committez sur une branche.

Si cet article vous a plu et que vous souhaitez progresser sur Git, poursuivez avec nos cours Intermediate Git et Intermediate GitHub Concepts.