git stash: één bestand zonder de rest te verliezen

Een code review komt binnen terwijl drie bestanden half bewerkt zijn en er maar één mag bewegen. Alles stashen en de andere twee opnieuw typen is het ritueel dat niemand mist.

TL;DR: git stash push -m "waarom" -- <pad> stashet exact de genoemde paden en laat de rest van je vieze boom met rust. Haal de wijzigingen terug met git stash pop (of trek één bestand uit elke stash met git restore --source stash@{0} -- <pad>). De pathspec-vorm kwam met git 2.13, uitgebracht in mei 2017 — elke toolchain van de afgelopen acht jaar heeft hem.

git stash push -m "app.conf prod tweak" -- app.conf
git stash list
# stash@{0}: On main: app.conf prod tweak
git stash pop

Stash het bestand, niet de boom.

Hoe stash je slechts één bestand in git?

Een kale git stash veegt de hele werkboom schoon — elke bijgehouden wijziging gaat de stash in en alles keert terug naar HEAD. Dat is de verkeerde vorm als de vieze boom gemengd is: één bestand is klaar om te overhandigen, de rest is eerlijk gezegd onaf. Het antwoord is het werkwoord push met een pathspec, volgens de git-stash-documentatie:

# voor: drie vieze bestanden
$ git status --short
 M app.conf
 M notes.md
 M main.py

# alleen app.conf stashen
$ git stash push -m "app.conf prod tweak" -- app.conf
Saved working directory and index state On main: app.conf prod tweak

$ git status --short
 M notes.md
 M main.py

app.conf is terug op zijn gecommitte staat en zit in stash@{0}; notes.md en main.py bewogen geen milimeter. Het -m-bericht is optioneel maar zijn drie seconden waard zodra git stash list meer dan één invoer toont — stashen die “WIP” heten, verouderen slecht.

Twee details die tellen:

• De pathspec komt na --. Alles na de dubbele streep zijn paden, geen vlaggen. Dezelfde conventie als git checkout -- <pad> en niet decoratief: in oudere versies verschilden git stash push -- main.py en git stash push main.py — een kaal pad kon verkeerd gelezen worden.
• Ongevolgde bestanden vragen om -u. een spiksplinternieuw bestand heeft geen bijgehouden geschiedenis om te stashen, dus een kale push slaat het over. git stash push -u -- newfile.py neemt het mee; -a gaat verder en veegt ook genegeerde bestanden op.

Hoe stash je een deel van één bestand?

Wanneer het bestand zelf half klaar is — drie goede hunks, één gênante — hakt de interactieve flow het in stukken:

git stash -p            # of: git stash push -p

Git loopt elk hunk langs en vraagt Stash this hunk [y,n,q,a,d,j,g,/,e,p,?]?. Antwoord y voor de hunks die de stash in gaan, n voor de hunks die blijven. Het resultaat is een stash met alleen het goedgekeurde, en de rest van het bestand blijft viezig in de boom. Dezelfde hunk-voor-hunk-machinerie drijft ook git add -p aan, dus de reflex verhuist mee.

	git stash push -- <pad>	git stash -p
Granulariteit	hele bestanden	losse hunks
Snelheid	één commando, scriptbaar	interactief, hunk voor hunk
Herhaalbaar in CI	ja (paden als argumenten)	nee — vraagt een mens achter de prompt
Het beste voor	“dit bestand, de rest niet”	“deze wijziging, die andere niet”
Sinds	git 2.13 (mei 2017)	al lang beschikbaar

Vuistregel uit het model van de docs zelf: pathspec als de grens het bestand is, -p als die erbinnen ligt.

Hoe haal je een gestasht bestand terug?

git stash pop herstelt stash@{0} en verwijdert de invoer. Dat is de normale route — maar pop is alles-of-niets per stash, en een conflict breekt de pop af met de invoer behouden. Twee fijnere opties:

# 1. toepassen zonder te verwijderen (gevarenloos herhaalbaar)
git stash apply stash@{0}

# 2. ÉÉN bestand uit een stash trekken, de invoer blijft staan
git restore --source stash@{0} -- app.conf
# oudere spelling van dezelfde operatie (vóór 2.23):
git checkout stash@{0} -- app.conf

De restore/checkout-vorm beantwoordt het geval “drie wijzigingen samen gestasht, nu heb ik er maar één nodig” — hij kopieert de gestashte inhoud van dat pad naar de werkboom en laat stash@{0} staan. Let op: hij overschrijft de kopie in de werkboom; als de huidige bewerkingen op dat pad ertoe doen, eerst diffen:

git diff stash@{0} -- app.conf

Stashen worden bewaard als echte commits op een reflog-achtige stapel — daarom accepteert stash@{0} elke commit-ish-syntax, en is een per ongeluk geslopen stash terug te halen uit de reflog totdat de garbage collector hem opeet.

Wanneer is stash het verkeerde gereedschap?

Een stash is een kladblok, geen branch: geen naam in git branch, geen review, geen standaard getoonde diff, en invoeren stapelen zich geruisloos op tot vergetelheid. Als het werk in uitvoering contextwissels tussen machines of dagen moet overleven, commit het op een branch — meegedragen geschiedenis verslaat een naamloze stapel. Wanneer die geparkeerde commits later ergens anders moeten landen, vervoert git cherry-pick ze. En als het doel ongedaan maken is in plaats van parkeren, geldt de beslisboom uit de laatste commit ongedaan maken.

Het eerlijke storingenboek, allemaal uit het gedocumenteerde gedrag:

Symptoom	Oorzaak	Fix
Bestand ontbreekt na stash	ongevolgde paden worden overgeslagen	git stash push -u -- <pad>
error: Your local changes ... would be overwritten bij pop	het pad veranderde sinds de stash	commit of stash de nieuwe staat, dan pop
Teruggehaalde wijzigingen verdwenen	de pop botste op een conflict en brak af	los op, dan git stash apply
“Welke stash was het ook alweer?”	naamloze hoop stashen	-m-berichten, elke keer

De releasenotitie van mei 2017 die pathspec toevoegde aan git stash push is acht jaar oud, en het merendeel van het spiergeheugen rond git stash is ouder. Een herlezing waard: het veegen van de hele boom is tegenwoordig het uitzonderingsgeval, niet de standaard.