Git stash d'un seul fichier : garez le fichier, pas l'arbre

■ space · couloir de prose

■ la réponse d'abord

git stash push -m "why" -- <path> gare exactement le fichier nommé ; tout autre fichier sale ne bouge jamais.

Un seul fichier ressorti d'un stash : git restore --source stash@{0} -- <path> — l'entrée reste.

La forme pathspec existe depuis git 2.13 (mai 2017) ; les fichiers non suivis ont besoin de -u.

LA SCISSURE

Trois fichiers sales, un seul doit bouger. Regardez l'arbre se scinder — un fichier au stash, deux ne bougent jamais :

AVANT · git status --short

 M app.conf   ← must move
 M notes.md
 M main.py

APRÈS

 M notes.md   ← never moved
 M main.py    ← never moved

stash@{0}: On main: app.conf prod tweak

app.conf est revenu à son état commité et siège dans stash@{0} — le message -m gagne ses trois secondes dès que git stash list a plus d'une entrée ; les noms comme « WIP » vieillissent mal

LE PATHSPEC EST TOUTE L'ASTUCE

Un git stash balaie l'arbre de travail entier — toute modification suivie entre, tout revient à HEAD. Mauvaise forme quand l'arbre sale est mixte : un fichier prêt à rendre, le reste vraiment inachevé. Deux détails à connaître :

Le pathspec vient après --. Tout ce qui suit le double tiret est des chemins, pas des drapeaux — même convention que git checkout -- <path>, et pas décorative : les vieilles versions de git pouvaient mal lire un chemin nu.
Les fichiers non suivis ont besoin de -u. Un fichier tout neuf n'a aucun historique suivi à stasher, donc un push nu le passe. git stash push -u -- newfile.py l'inclut ; -a va plus loin et balaie aussi les fichiers ignorés.

DEMI-FICHIER : LA SCISSURE INTERACTIVE

Quand c'est le fichier lui-même à moitié prêt — trois hunks bons, un honteux — git stash -p (ou git stash push -p) parcourt chaque hunk et demande Stash this hunk [y,n,q,a,d,j,g,/,e,p,?]?. Répondez y pour les hunks qui appartiennent au stash, n pour ceux qui restent ; le résultat est un stash ne contenant que ce que vous avez approuvé. Les mêmes engrenages hunk par hunk alimentent git add -p, donc le réflexe se transfère. Les deux granularités, côte à côte :

	`git stash push -- <path>`	`git stash -p`
Granularité	fichiers entiers	hunks individuels
Vitesse	une commande, scriptable	interactif, hunk par hunk
Répétable en CI	oui (chemins en arguments)	non — il faut un humain à l'invite
Idéal pour	« ce fichier, pas le reste »	« ce changement, pas celui-là »
Depuis	git 2.13 (mai 2017)	disponible depuis longtemps

Règle du pouce tirée du modèle des docs eux-mêmes : pathspec quand la frontière est le fichier, -p quand la frontière est à l'intérieur.

UN FICHIER RESORTI

git stash pop restaure stash@{0} et supprime l'entrée — le chemin normal, mais pop est tout-ou-rien par stash, et un conflit avorte le pop en préservant l'entrée. Deux options plus fines :

# 1. apply without dropping (safe re-run)
git stash apply stash@{0}

# 2. pull ONE file out of a stash, leave the entry intact
git restore --source stash@{0} -- app.conf
# pre-2.23 spelling of the same operation:
git checkout stash@{0} -- app.conf

vérification : git stash list après le restore → stash@{0} toujours debout — seul pop supprime l'entrée

QUAND LE STASH EST LE MAUVAIS OUTIL

Le stash est un brouillon, pas une branche. Les stashes ne vivent que sur votre machine, ne portent pas de message au-delà de la ligne unique, et sont d'une facilité d'oubli légendaire — git stash list est un genre à part entière.git switch -c wip-labels Le travail qui doit survivre des jours, voyager entre machines, ou porter un vrai message de commit, appartient à une branche :

■ cachet d'honnêteté Testé sur : git 2.13+ pathspec · git 2.23+ restore · tous les majeurs. Première publication 2026-09-21. La forme pathspec, le drapeau -u pour les chemins non suivis, l'invite de hunk et l'orthographe restore-depuis-stash sont le comportement de stash documenté de git — la sortie status avant/après ci-dessus est exactement ce que la séquence imprime.

fin du fichier unique · rien de fetché · tout est local