git stash: eine einzelne Datei, ohne den Rest zu verlieren

Ein Code-Review kommt rein, während drei Dateien halb bearbeitet sind und nur eine davon sich bewegen darf. Alles zu stashen und die anderen beiden Dateien neu zu tippen ist das Ritual, das niemand vermisst.

TL;DR: git stash push -m "warum" -- <pfad> stasht exakt die genannten Pfade und lässt den Rest deines schmutzigen Baums in Ruhe. Zurückholen mit git stash pop (oder eine einzelne Datei aus jedem Stash herausziehen mit git restore --source stash@{0} -- <pfad>). Die Pathspec-Form kam mit git 2.13, veröffentlicht im Mai 2017 — jede Toolchain der letzten acht Jahre hat sie.

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 die Datei, nicht den Baum.

Wie stashe ich nur eine einzelne Datei in git?

Ein nacktes git stash fegt den ganzen Arbeitsbaum — jede getrackte Änderung wandert in den Stash, alles zurück auf HEAD. Das ist die falsche Form, wenn der schmutzige Baum gemischt ist: eine Datei ist reif zur Übergabe, der Rest ist ehrlich unfertig. Die Lösung ist das Verb push mit einem Pathspec, laut git-stash-Dokumentation:

# vorher: drei schmutzige Dateien
$ git status --short
 M app.conf
 M notes.md
 M main.py

# nur 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 ist zurück auf dem commiteten Stand und liegt in stash@{0}; notes.md und main.py haben sich nie bewegt. Die -m-Nachricht ist optional, aber die drei Sekunden wert, sobald git stash list mehr als einen Eintrag zeigt — Stashes namens „WIP” altern schlecht.

Zwei Details, die zählen:

• Der Pathspec kommt nach --. Alles nach dem Doppelstrich sind Pfade, keine Flags. Dieselbe Konvention wie git checkout -- <pfad>, und sie ist nicht dekorativ: git stash push -- main.py und git stash push main.py unterscheiden sich in älteren Versionen, wo ein nackter Pfad falsch gelesen werden konnte.
• Ungetrackte Dateien brauchen -u. Eine brandneue Datei hat keine getrackte Historie zum Stashen, ein nacktes push überspringt sie. git stash push -u -- newfile.py nimmt sie auf; -a geht weiter und fegt auch ignorierte Dateien ein.

Wie stashe ich nur einen Teil einer Datei?

Wenn die Datei selbst halbfertig ist — drei gute Hunks, ein peinlicher — zerlegt der interaktive Flow sie:

git stash -p            # oder: git stash push -p

Git geht jeden Hunk durch und fragt Stash this hunk [y,n,q,a,d,j,g,/,e,p,?]?. Antworte y für die Hunks, die in den Stash gehören, n für die, die bleiben. Das Ergebnis ist ein Stash nur mit dem Freigegebenen, der Rest der Datei bleibt schmutzig im Baum. Dieselbe Hunk-für-Hunk-Maschinerie treibt git add -p an — der Reflex überträgt sich.

	git stash push -- <pfad>	git stash -p
Granularität	ganze Dateien	einzelne Hunks
Tempo	ein Befehl, skriptbar	interaktiv, Hunk für Hunk
In CI wiederholbar	ja (Pfade als Argumente)	nein — braucht einen Menschen am Prompt
Am besten für	„diese Datei, nicht der Rest”	„diese Änderung, nicht die andere”
Seit	git 2.13 (Mai 2017)	seit Langem verfügbar

Faustregel nach dem Modell der Doku: Pathspec, wenn die Grenze die Datei ist, -p, wenn sie darin liegt.

Wie hole ich eine gestashte Datei zurück?

git stash pop stellt stash@{0} wieder her und löscht den Eintrag. Das ist der normale Weg — aber Pop ist alles-oder-nichts pro Stash, und ein Konflikt bricht den Pop ab, wobei der Eintrag erhalten bleibt. Zwei feinere Optionen:

# 1. anwenden ohne Löschen (gefahrlos wiederholbar)
git stash apply stash@{0}

# 2. EINE Datei aus einem Stash ziehen, Eintrag bleibt bestehen
git restore --source stash@{0} -- app.conf
# Schreibweise vor 2.23 derselben Operation:
git checkout stash@{0} -- app.conf

Die restore/checkout-Form beantwortet den Fall „drei Änderungen zusammen gestasht, jetzt wird nur eine davon gebraucht” — sie kopiert den gestashten Inhalt dieses Pfads in den Arbeitsbaum und lässt stash@{0} stehen. Beachte: Sie überschreibt die Kopie im Arbeitsbaum; wenn die aktuellen Änderungen an diesem Pfad zählen, zuerst diffen:

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

Stashes sind echte Commits auf einem reflog-artigen Stack — deshalb akzeptiert stash@{0} jede Commit-ish-Syntax, und deshalb ist ein versehentlich gelöschter Stash über den Reflog erreichbar, bis die Garbage Collection ihn frisst.

Wann ist ein Stash das falsche Werkzeug?

Ein Stash ist ein Notizblock, kein Branch: kein Name in git branch, kein Review, kein Diff standardmäßig sichtbar, und Einträge stapeln sich still bis zum Vergessen. Wenn die Arbeit in Arbeit Maschinen- oder Tageswechsel überleben muss, committe sie auf einen Branch — angehängte Historie schlägt einen namenlosen Stack. Wenn diese geparkten Commits später woanders landen sollen, transportiert sie git cherry-pick hinüber. Und wenn das Ziel Rückgängigmachen statt Parken ist, gilt der Entscheidungsbaum aus letzten Commit rückgängig machen.

Das ehrliche Register der Fehlermodi, alle aus dem dokumentierten Verhalten:

Symptom	Ursache	Fix
Datei fehlt nach dem Stash	ungetrackte Pfade werden übersprungen	git stash push -u -- <pfad>
error: Your local changes ... would be overwritten beim Pop	der Pfad hat sich seit dem Stash geändert	neuen Zustand commiten oder stashen, dann pop
Gepoppte Änderungen verschwunden	Pop stieß auf einen Konflikt und brach ab	lösen, dann git stash apply
„Welcher Stash war das nochmal?”	namenloser Stapel von Stashes	-m-Nachrichten, immer wieder

Die Release-Notiz vom Mai 2017, die Pathspec-Support für git stash push einführte, ist acht Jahre alt, und der größte Teil des git stash-Muskelgedächtnisses ist älter. Eine Neulernens wert: Der Ganzbaum-Fegewurf ist heute der Sonderfall, nicht der Standard.