Mitten in einer Aufgabe klingelt der Support: „Bitte sofort einen Hotfix in den Main-Branch!“ – aber im aktuellen Branch liegen noch halbfertige Änderungen. Genau für solche Momente ist Git Stash gedacht: Es legt lokale Änderungen temporär ab (wie ein Zwischenablage-Regal) und macht das Arbeitsverzeichnis wieder sauber, ohne dass ein Commit nötig ist.
Der Vorteil: Änderungen bleiben erhalten, können später gezielt zurückgeholt werden – und der Wechsel zu einem anderen Branch klappt ohne „dirty working tree“-Probleme. Damit das zuverlässig funktioniert, lohnt es sich, ein paar Grundregeln zu kennen: Was wird eigentlich gestasht, wie geht man mit mehreren Stashes um, und wie vermeidet man Konflikte beim Zurückholen?
Wofür Git Stash geeignet ist (und wofür nicht)
Typische Alltagssituationen
Ein Stash ist eine gute Lösung, wenn Änderungen kurzzeitig „geparkt“ werden sollen:
- Branch wechseln, obwohl noch nicht alles fertig ist
- Schnell einen Pull machen, ohne halbfertige Dateien zu mischen
- Ein Hotfix muss sofort umgesetzt werden
- Man möchte experimentieren, ohne direkt Commits anzulegen
Wann ein Commit die bessere Wahl ist
Ein Stash ist bewusst temporär. Wenn Änderungen länger leben oder mit dem Team geteilt werden sollen, ist ein normaler Commit meist sauberer. Das gilt besonders, wenn:
- die Änderungen mehrere Stunden/Tage liegen bleiben,
- die Arbeit abgesichert und nachvollziehbar sein soll (History),
- andere Personen die Änderung brauchen.
Als Faustregel: Stash für „kurz weglegen“, Commit für „bewusst versionieren“.
Was beim Stashen wirklich passiert
Working Tree und Index kurz erklärt
Git unterscheidet grob zwei Bereiche: den Working Tree (Dateien auf der Platte) und den Index (auch „Staging Area“, also vorgemerkte Änderungen für den nächsten Commit). Ein Stash kann – je nach Aufruf – beide Bereiche sichern.
Wichtig: Standardmäßig nimmt Git nur Änderungen an bereits getrackten Dateien mit. Neue Dateien (untracked) bleiben oft liegen, wenn man das nicht explizit verlangt.
Welche Änderungen landen im Stash?
Im Standardfall (git stash) werden Änderungen an getrackten Dateien weggestaut und das Arbeitsverzeichnis wird zurückgesetzt. Untracked Dateien und ignorierte Dateien (.gitignore) bleiben standardmäßig unberührt.
Wenn auch neue Dateien mit sollen, wird ein anderer Modus gebraucht (siehe unten). Das ist eine häufige Fehlerquelle: Man glaubt, „alles ist verstaut“, aber die neu erstellte Datei liegt noch im Verzeichnis.
Die wichtigsten Git-Stash-Befehle für den Alltag
Änderungen weglegen: stash push mit Nachricht
Der moderne Weg ist git stash push. Praktisch ist eine Nachricht, damit später klar ist, was drinsteckt:
git stash push -m „WIP: Formular-Validierung“
Damit entsteht ein neuer Eintrag in der Stash-Liste.
Stashes ansehen und unterscheiden
Mit git stash list werden alle Stashes angezeigt. Typisch sieht das so aus: stash@{0}, stash@{1}, … (die Zahl ist die Position in der Liste, 0 ist der jüngste).
Wenn unklar ist, was ein Stash enthält, hilft ein Blick in die Änderungen. Je nach Bedarf:
- kurzer Überblick (Dateinamen)
- Detailansicht (Diff)
So vermeidet man, den falschen Stash zurückzuholen.
Zurückholen: apply vs. pop
Zum Wiederherstellen gibt es zwei typische Varianten:
- git stash apply: spielt den Stash ein, lässt ihn aber in der Liste.
- git stash pop: spielt den Stash ein und entfernt ihn danach aus der Liste (wenn alles klappt).
Im Alltag ist „apply“ oft sicherer, weil der Stash als Backup liegen bleibt, bis klar ist, dass alles sauber wiederhergestellt ist. Erst danach kann er gelöscht werden.
Nur einen bestimmten Stash anwenden
Wenn mehrere Stashes existieren, sollte immer gezielt ausgewählt werden, z. B. stash@{2}. So lassen sich parallele Aufgaben sauber trennen: Hotfix, Feature-Arbeit, Experiment.
Untracked Dateien und Teil-Stashes sauber handhaben
Neue Dateien mitnehmen
Wenn neue Dateien mit in den Stash sollen, braucht es die passende Option. Sonst bleiben sie als „untracked“ im Working Tree und blockieren manchmal den Branch-Wechsel. In solchen Fällen ist es sinnvoll, bewusst zu entscheiden: Soll die neue Datei wirklich mit in den Stash, oder gehört sie eher in einen frühen Commit?
Nur Teile stashen (wenn nicht alles weg soll)
Manchmal sollen nicht alle Änderungen weggelegt werden, sondern nur bestimmte Hunks (Teilstücke in einer Datei). Das ist hilfreich, wenn in einer Datei bereits zwei Themen vermischt sind: ein Bugfix und eine neue Funktion. Dann kann ein interaktives Vorgehen die Änderungen trennen, bevor der Branch gewechselt wird.
Das spart Zeit, weil nachher weniger Konflikte und weniger „Aufräumen“ entstehen.
Konflikte beim Zurückholen vermeiden
Warum es zu Konflikten kommen kann
Ein Stash ist kein magischer Safe, der immer konfliktfrei zurückkommt. Konflikte entstehen, wenn sich die gleichen Stellen in Dateien seit dem Stashen verändert haben – zum Beispiel durch einen Pull, einen Rebase oder durch eigene Commits im Ziel-Branch.
Das ist normal: Git muss dann entscheiden, wie die Änderungen zusammenpassen, und bittet um Hilfe.
Praktische Strategien, die Konflikte reduzieren
- Stash nur kurz liegen lassen und zeitnah wieder anwenden.
- Vor dem Anwenden prüfen, ob der Ziel-Branch stark weitergelaufen ist.
- Wenn möglich erst pull/rebase, dann stashed Änderungen einspielen.
- Größere Refactorings nicht per Stash „hin- und herschieben“, sondern lieber committen.
Wer häufig Branches umsortiert, profitiert auch von einem sauberen Branch-Workflow. Passend dazu: Git Branching verstehen – Workflow für Teams ohne Chaos.
Ein kleiner Entscheidungsbaum für die richtige Vorgehensweise
- Änderungen sind wirklich nur kurzzeitig und lokal?
- Ja
- Arbeitsverzeichnis muss sauber werden: Stash nutzen
- Nur einzelne Änderungen weglegen: interaktiv stashen
- Nein
- Änderungen sollen nachvollziehbar sein oder länger liegen: committen (ggf. als WIP-Commit)
- Änderungen sollen ins Team: Branch pushen und PR/MR nutzen
- Ja
Kurze Box zum direkten Umsetzen
- Unfertige Änderungen kurz weglegen: git stash push -m „WIP: …“
- Liste prüfen: git stash list
- Passenden Stash testweise anwenden: git stash apply stash@{0}
- Wenn alles passt: Stash danach löschen oder per pop entfernen
- Bei Konflikten: wie bei einem Merge auflösen, dann normal committen
Aufräumen und Ordnung halten bei vielen Stashes
Stashes gezielt löschen
Ein Stash ist schnell erstellt – und genauso schnell vergisst man ihn. Deshalb lohnt sich regelmäßiges Aufräumen: Einzelne Stashes können gezielt entfernt werden, wenn sie nicht mehr gebraucht werden. So bleibt die Liste übersichtlich und das Risiko sinkt, versehentlich alte Änderungen wieder einzuspielen.
Stash als eigener Branch (wenn es doch mehr wird)
Manchmal merkt man erst später: Der „kurz geparkte“ Stand ist doch ein eigenes Thema. Dann ist ein Branch oft die bessere Form als ein Stash, weil daraus normale Commits werden können. Das macht die Arbeit nachvollziehbar und einfacher zu reviewen.
Wenn ohnehin größere Umstrukturierungen anstehen, ist auch ein Blick auf Rebase/History-Pflege sinnvoll: Git Rebase verstehen – Branches sauber zusammenführen.
Häufige Missverständnisse aus der Praxis
„Stash ist ein Backup“
Ein Stash ist keine Backup-Strategie. Er ist lokal, nicht automatisch geteilt und kann bei unvorsichtiger Nutzung verloren gehen (zum Beispiel bei einem kompletten Aufräumen ohne Prüfung). Für echte Absicherung sind Commits und ein Remote-Repository die bessere Wahl.
„Im Stash ist garantiert alles drin“
Standardmäßig landen nicht automatisch neue Dateien und ignorierte Dateien im Stash. Vor allem bei neu angelegten Konfig-Dateien oder neuen Komponenten sorgt das oft für Verwirrung. Wer häufiger in diese Falle läuft, sollte vor dem Stashen kurz prüfen, was Git als untracked anzeigt.
„Nach pop ist es erledigt“
Nach einem „pop“ ist der Stash weg, aber nicht automatisch die Aufgabe. Wenn direkt Konflikte entstehen oder ein Teil der Änderungen nicht wie erwartet passt, fehlt das Sicherheitsnetz. Deshalb ist „apply, prüfen, dann löschen“ oft der robustere Ablauf.
Wer im Alltag häufiger Probleme durch „lokale Überraschungen“ hat, profitiert außerdem von klaren Regeln für Umgebungsvariablen und Konfiguration: Environment Variables verstehen – .env sicher nutzen.
