Git Stash Pop: Arbeit bewahren beim Branch-Wechsel

Wenn du halb fertige Arbeit hast, die noch nicht commit-reif ist, du aber sofort den Kontext wechseln musst, dann mach keinen "WIP"-Commit. Und bitte kopiere deine Änderungen nicht in eine Textdatei wie 2005. git stash ist alles, was du brauchst.

Dieser Befehl ist die erste Wahl, um nicht eingecheckte Arbeit aufzubewahren, während du den Kontext wechselst. Er speichert Änderungen vorübergehend, damit du dringende Aufgaben auf anderen Branches erledigen und danach alles genau dort wiederherstellen kannst, wo du aufgehört hast.

In diesem Artikel zeige ich dir, wie git stash pop funktioniert, wann du es git stash apply vorziehen solltest und wie du zurechtkommst, wenn Konflikte unvermeidlich auftauchen.

Wenn du neu bei Git bist und Stashing noch verwirrend findest, solltest du erst die Grundlagen beherrschen. Unsere Kurse Introduction to Git und Introduction to GitHub bringen dich schnell in Fahrt.

Git Stash verstehen

Git Stash ist dein temporärer Speicher für nicht eingecheckte Änderungen.

Denk daran wie an die Zwischenablage für deine Arbeit. Du hast Änderungen im Working Directory, die noch nicht commit-reif sind, musst aber den Branch wechseln oder Updates vom Remote holen. Statt Arbeit zu verlieren oder einen WIP-Commit zu machen, stashst du sie.

Der Befehl speichert deine Modifikationen und setzt dein Working Directory auf den HEAD-Commit zurück.

Die Idee hinter Stashing in Git

Stashing löst ein simples Problem: Git lässt dich mit nicht eingecheckten Änderungen nicht den Branch wechseln.

Angenommen, du arbeitest an einem Feature, als ein Bug-Report reinkommt. Du musst sofort auf einen anderen Branch, hast aber halbfertigen Code und geänderte Dateien. Ein Commit ergibt keinen Sinn, weil die Arbeit unvollständig ist. Ein erzwungener Checkout würde Änderungen verlieren.

Genau dann stashst du.

Hier sind die häufigsten Szenarien, in denen Stashing hilft:

1. Branch-Wechsel für dringende Aufgaben: Du bist mitten im Feature, musst aber einen Produktionsbug fixen.
2. Remote-Änderungen ziehen: Ein Teammitglied hat gepusht und du musst pullen, hast aber lokale Modifikationen.
3. Unsaubere Commits vermeiden: Du bist noch nicht bereit zu committen, brauchst aber ein sauberes Working Directory fürs Rebasen oder Mergen.
4. Experimentellen Code sichern: Du willst einen anderen Ansatz ausprobieren, ohne die aktuelle Arbeit zu verlieren

Stashing ist schnell und rückgängig zu machen – keine Commit-Messages oder Branchnamen nötig.

Die Stash-Stack-Architektur

Git verwaltet Stashes in einem LIFO-Stack (Last-in-first-out).

Jedes Mal, wenn du stashst, legt Git einen neuen Eintrag oben auf den Stack. Der jüngste Stash ist stash@{0}, ältere rutschen nach unten: stash@{1}, stash@{2} usw.

Unter der Haube ist jeder Stash eigentlich ein Commit – genauer gesagt ein Set aus Commits. Git erzeugt eine Multi-Parent-Commit-Struktur, die Folgendes speichert:

1. Deine Änderungen im Working Directory
2. Deine gestagten Änderungen (den Index)
3. Ungetrackte Dateien (wenn du das u-Flag nutzt)

Diese Struktur bedeutet: Stashes sind nicht nur Schnappschüsse. Es sind vollständige Commits, die Git später wieder in dein Working Directory mergen kann.

Du kannst Stashes auf zwei Arten referenzieren – per Index mit der Syntax stash@{0} oder über git stash list und den vergebenen Nachrichtentext. Der Index ist für jüngste Stashes schneller, Nachrichten sind besser, wenn du mehrere Stashes hast.

So sieht ein typischer Stash-Stack aus:

Das Präfix WIP on bedeutet, du hast git stash ohne Nachricht genutzt. Das Präfix On zeigt, dass du eine eigene Nachricht mit git stash push -m angegeben hast.

Stashes leben nur in deinem lokalen Repository – sie werden nicht zum Remote gepusht. So bleibt deine temporäre Arbeit genau dort, wo sie hingehört: auf deinem Rechner, bereit zur Wiederherstellung.

Stashes erstellen, verwalten und untersuchen

Der einfache Befehl git stash reicht zum Start, ist aber bequemlich. Du landest mit einem Stapel aus "WIP on branch-name"-Einträgen, die nichts über den Inhalt verraten. Nach sechs Wochen weißt du nicht mehr, welcher Stash den Bugfix enthält und welcher den halbfertigen Refactor.

Ich zeige dir jetzt, wie du es von Anfang an richtig machst.

Stashes mit sinnvoller Metadaten-Beschriftung anlegen

Am einfachsten stashst du mit git stash:

git stashBereitgestellt von

Das speichert deine Änderungen, aber die Nachricht "WIP on main" sagt wenig. Ohne Inspektion siehst du nicht, was drin ist.

Nutze stattdessen git stash push -m mit einer aussagekräftigen Nachricht:

git stash push -m "Updated file.txt"Bereitgestellt von

Jetzt ist deine Stash-Liste wirklich hilfreich:

Der Unterschied ist klar. Ein Eintrag sagt dir exakt, was du getan hast, der andere lässt dich raten.

Schreibe Nachrichten, als würdest du deinem zukünftigen Ich eine Notiz hinterlassen. "Auth-Logik hinzufügen", "Navbar-Bug fixen" oder "Mit neuem API-Design experimentieren" sind immer besser als generische WIP-Meldungen.

Ungetrackte oder ignorierte Dateien einbeziehen

Standardmäßig speichert git stash nur getrackte Dateien – also Dateien, die Git bereits kennt.

Ungetrackte Dateien bleiben im Working Directory. Das überrascht viele, wenn sie stashen, den Branch wechseln und ihre neuen Dateien immer noch sehen.

So sieht das aus:

echo "new_feature.py" > new_feature.py
git stashBereitgestellt von

Die Datei wurde nicht gestasht, weil Git sie noch nicht trackt:

Um das zu umgehen, nutze das -u-Flag, um ungetrackte Dateien zu stashen:

git stash push -u -m "Added a Python file for a new cool feature"Bereitgestellt von

Damit stashst du getrackte und ungetrackte Dateien. Dein Working Directory ist komplett sauber.

Tipp: Mit dem -a-Flag beziehst du auch ignorierte Dateien ein. Es stashst getrackte, ungetrackte und Dateien aus deiner .gitignore. Das brauchst du selten, außer beim Debuggen von Build-Problemen oder wenn du wirklich alles in einem komplett sauberen Schnappschuss sichern willst.

Hier eine kleine Merkhilfe, wann welches Flag sinnvoll ist:

1. Kein Flag: Du hast nur bestehende Dateien geändert

2. u-Flag: Du hast neue, noch nicht getrackte Dateien hinzugefügt

3. a-Flag: Du willst wirklich alles sichern, inkl. Build-Outputs oder temporärer Dateien

Meistens nutzt du -u. Das ist die sicherste Wahl, wenn du während der Entwicklung neue Dateien angelegt hast.

Teilweises oder selektives Stashing

Du musst nicht alles im Working Directory stashen.

Sagen wir, du hast zwei Bugs gefixt, willst aber nur einen davon stashen. Oder du hast Änderungen in fünf Dateien, aber nur drei gehören zum Feature, das du sichern willst.

Du kannst mit einer Pathspec gezielt Dateien stashen:

git stash push -m "New files" new_file.txt new_file_2.txtBereitgestellt von

Dadurch werden nur new_file.txt und new_file_2.txt gestasht. Alles andere bleibt im Working Directory.

Du kannst auch Wildcards verwenden:

git stash push -m "Stash all txt files" *.txtBereitgestellt von

Oder du nutzt --patch für interaktives Stashing:

git stash push --patchBereitgestellt von

Git geht Änderung für Änderung durch und fragt, ob du sie stashen willst. Du antwortest mit y (yes), n (no) oder s (Hunk in kleinere Teile splitten).

Praktisch, wenn zusammenhängende und unabhängige Änderungen in derselben Datei stecken. Du stashst die Feature-Arbeit und lässt Debug-Code zurück.

So sieht die interaktive Abfrage aus:

Stashes auflisten und untersuchen

Wie du gesehen hast, zeigt git stash list alles, was du gestasht hast:

Der jüngste Stash ist immer stash@{0}. Ältere rutschen im Index nach unten.

Mit guten Nachrichten kannst du die Liste scannen und weißt sofort, was drinsteckt. Ohne musst du jeden Stash einzeln prüfen.

Nutze git stash show für eine Zusammenfassung:

Du siehst, welche Dateien geändert wurden und wie viele Zeilen hinzugefügt oder entfernt sind.

Alternativ zeigt git stash show -p das vollständige Diff:

Das -p-Flag zeigt die tatsächlichen Codeänderungen – wie git diff. So verifizierst du, dass du den richtigen Stash poppst, bevor du git stash pop ausführst.

Was Git Stash Pop tatsächlich macht

Kommen wir dazu, was git stash pop genau macht und warum du es nutzt.

Grundverhalten und Syntax

Der Befehl git stash pop macht zwei Dinge: Er wendet deine gestashten Änderungen an und löscht diesen Stash anschließend aus dem Stack.

Die Basissyntax:

git stash popBereitgestellt von

Das poppt den jüngsten Stash (stash@{0}) und entfernt ihn aus der Stash-Liste.

Du kannst auch einen spezifischen Stash per Index poppen:

git stash pop stash@{1}Bereitgestellt von

Das wendet stash@{1} an und entfernt ihn. Aber Achtung – die verbleibenden Stashes rücken auf. Aus stash@{2} wird stash@{1} usw.

So verarbeitet Git ein Stash Pop

Wenn du git stash pop ausführst, macht Git im Hintergrund einen Drei-Wege-Merge.

Es vergleicht drei Zustände:

1. Den Basis-Commit (an dem du den Stash erstellt hast)
2. Deinen aktuellen HEAD-Commit
3. Die gestashten Änderungen

Wenn der Merge ohne Konflikte gelingt, wendet Git deine Änderungen an und entfernt den Stash. Dein Working Directory sieht genau so aus wie vor dem Stash.

Hier ein einfaches Workflow-Beispiel:

# Du arbeitest an einem Feature
echo "new feature code" >> feature.py
git stash push -m "Half-finished feature work"

# Wechsel auf neuen Branch und unabhängige Änderungen
git checkout bugfix
echo "bug fix" >> bugfix.py
git add bugfix.py
git commit -m "Fix critical bug"

# Zurück auf den anderen Branch
git checkout main

# Gestashte Arbeit wiederherstellen
git stash popBereitgestellt von

Kann Git nicht sauber mergen, gibt es Konflikte. Der Stash bleibt im Stack, weil der Pop nicht erfolgreich abgeschlossen wurde. Du siehst Konfliktmarker in den Dateien – wie bei einem normalen Merge-Konflikt.

Bei Konflikten musst du sie manuell lösen, die korrigierten Dateien stagen und committen. Der Stash verschwindet nicht automatisch, daher musst du nach dem Lösen git stash drop ausführen.

Stashes über Branches hinweg anwenden

Stashes sind nicht an einen bestimmten Branch gebunden.

Du kannst einen Stash auf bugfix erstellen, zu main wechseln und ihn dort poppen. Git ist egal, woher der Stash kommt – es versucht, die Änderungen auf den aktuellen Branch anzuwenden.

Daraus ergeben sich praktische Workflows:

1. Arbeit zwischen Branches verschieben: Du hast auf dem falschen Branch begonnen. Statt Reset und Arbeitsverlust stashst du, wechselst zum richtigen Branch und poppst dort.

2. Aufgaben neu ordnen: Du hast vor einer Woche experimentellen Code gestasht. Jetzt willst du ihn auf einem anderen Branch ausprobieren.

3. Änderungen in unterschiedlichen Kontexten testen: Du hast einen Bugfix gestasht und willst ihn vor dem Commit auf mehreren Branches testen. Nutze git stash apply statt pop, um den Stash zu behalten, teste auf verschiedenen Branches und pop ihn dort, wo du committen willst. Mehr dazu gleich.

Solange die Änderungen nicht mit deinem aktuellen Branch kollidieren, wird der Stash sauber angewendet – das ist der zentrale Punkt, den du dir merken solltest.

Git Stash Pop vs. Git Stash Apply

Oft stellt sich die Frage, ob git stash pop oder git stash apply besser ist.

Der Hauptunterschied: Stash bleibt bestehen oder nicht

Der Kernunterschied ist simpel: pop entfernt den Stash nach dem Anwenden, apply behält ihn im Stack.

Mit pop sagst du: "Fertig damit – anwenden und wegwerfen." Mit apply sagst du: "Das brauche ich vielleicht noch einmal."

Das wirkt sich auf deinen Workflow so aus:

1. Sicherheit: Wenn bei einem pop etwas schiefgeht und du wiederherstellen musst, ist der Stash weg. Mit apply bleibt er als Backup im Stack.

2. Aufräumen: pop hält deine Stash-Liste automatisch sauber. Bei apply musst du später mit git stash drop von Hand löschen.

Viele nutzen standardmäßig pop, weil es aufräumt. apply ist besser, wenn du nicht sicher bist, ob der Stash auf dem aktuellen Branch sauber funktioniert, oder wenn du dieselben Änderungen auf mehreren Branches testen willst.

Vorhersehbarkeit, Risiko und Index-Verschiebung

Hier wird pop knifflig – Indizes verschieben sich, wenn du aus der Mitte des Stacks poppst.

Angenommen, du hast drei Stashes:

stash@{0}: Feature work
stash@{1}: Bug fix
stash@{2}: Experimental codeBereitgestellt von

Wenn du stash@{1} poppst, rücken die übrigen auf:

stash@{0}: Feature work
stash@{1}: Experimental codeBereitgestellt von

Das kann problematisch sein, wenn du Git-Skripte schreibst oder mehrere Pops hintereinander ausführst. Du poppst stash@{1} und willst danach stash@{2} poppen – diesen Index gibt es nicht mehr.

Der Befehl apply hat dieses Problem nicht. Indizes verschieben sich nur, wenn du explizit git stash drop ausführst. Du kannst Stashes in beliebiger Reihenfolge anwenden, ohne dass sich der Stack unterm Hintern verändert.

Identische Konfliktbehandlung

Beide Befehle gehen mit Konflikten identisch um.

Wenn Git deine gestashten Änderungen nicht sauber mergen kann, setzt es Konfliktmarker in die Dateien. Der Unterschied liegt nur darin, was mit dem Stash passiert:

1. Mit pop: Der Stash bleibt im Stack, weil der Pop nicht erfolgreich abgeschlossen wurde

2. Mit apply: Der Stash bleibt im Stack (so oder so)

In beiden Fällen musst du Konflikte manuell lösen, die bereinigten Dateien mit git add stagen und den Stash mit git stash drop entfernen (bei apply).

Der Konflikt-Workflow ist identisch – der einzige Unterschied ist, ob der Stash bei Erfolg automatisch entfernt worden wäre.

Wann welchen Befehl wählen

Nutze git stash pop, wenn:

1. Du einen Stash einmalig anwendest und danach nicht mehr brauchst
2. Du deine Stash-Liste automatisch sauber halten willst
3. Du auf einem einzelnen Branch arbeitest und den Stash nicht anderswo benötigst

Nutze git stash apply, wenn:

1. Du dieselben Änderungen auf mehreren Branches testen willst
2. Du nicht sicher bist, ob der Stash sauber funktioniert
3. Du Git-Aktionen skriptest und vorhersehbare Indizes benötigst
4. Du ein Sicherheitsnetz willst, falls etwas schiefgeht

Konflikte beim Stash Pop handhaben

Konflikte entstehen, wenn Git deine gestashten Änderungen nicht sauber mergen kann. In diesem Abschnitt zeige ich dir, wie du damit umgehst.

Wann und warum Konflikte auftreten

Ein Konflikt entsteht während des Drei-Wege-Merge, den Git beim Pop durchführt.

Git vergleicht drei Versionen deines Codes:

1. Den Basis-Commit, an dem du den Stash erstellt hast
2. Deinen aktuellen HEAD-Commit
3. Die gestashten Änderungen

Wenn in beiden – aktuellem Branch und Stash – dieselben Zeilen geändert wurden, weiß Git nicht, welche Version gelten soll. Das ist ein Konflikt.

Häufige Ursachen für Konflikte beim Stash Pop:

1. Du hast dieselbe Datei in beiden Branches geändert: Du hast Änderungen gestasht, den Branch gewechselt und dieselbe Datei vor dem Pop erneut bearbeitet
2. Jemand anderes hat gepusht: Du hast Arbeit gestasht, Updates gepullt, und diese betreffen denselben Code
3. Du hast rebaset oder Commits cherry-gepickt: Der erwartete Basis-Commit existiert nicht mehr, was zu Merge-Unterschieden führt

Kurz gesagt: Je länger ein Stash liegen bleibt, desto wahrscheinlicher sind Konflikte beim Poppen.

Konflikt-Workflow

Bei einem Konflikt pausiert Git den Pop und markiert die Konflikte in deinen Dateien:

Deine Datei enthält jetzt Konfliktmarker:

Alles zwischen <<<<<<< Updated upstream und ======= ist dein aktueller Code. Alles zwischen ======= und >>>>>>> Stashed changes stammt aus dem Stash.

So gehst du vor:

1. Öffne die konfliktbehaftete Datei und entscheide, welche Version bleibt (oder kombiniere beides)

2. Entferne die Konfliktmarker (<<<<<<<, =======, >>>>>>>)

3. Stagere die bereinigte Datei mit git add

4. Lösche den Stash manuell mit git stash drop – er verschwindet nicht automatisch.

Alternative Strategien

Wenn du Konflikte nicht im aktuellen Branch lösen willst, nutze stattdessen git stash branch.

Der Befehl erstellt einen neuen Branch von dem Commit, an dem du den Stash erstellt hast, und wendet den Stash dort an:

git stash branch temp-featureBereitgestellt von

Git erstellt einen Branch namens temp-feature, checkt ihn aus und poppt deinen Stash darauf. Da der Branch exakt vom Commit startet, an dem du gestasht hast, gibt es keine Konflikte. Ich gehe dazu später noch detaillierter ein.

Du kannst einen fehlgeschlagenen Pop auch mit git reset --merge abbrechen:

git stash pop

# Es treten Konflikte auf

git reset --mergeBereitgestellt von

Das macht den Pop-Versuch rückgängig und setzt dein Working Directory auf den Zustand vor dem Pop zurück. Der Stash bleibt im Stack.

Laufende Stash-Operationen abbrechen

Wenn du einen Pop oder Apply gestartet hast und komplett zurück willst, hast du Optionen.

Bei Konflikten, mit deren Lösung du noch nicht begonnen hast, führe Folgendes aus:

git reset --mergeBereitgestellt von

Das bricht den Merge ab und bereinigt dein Working Directory. Alles ist wieder wie vor dem Stash-Befehl.

Wenn du Konflikte schon teilweise gelöst hast, nutze:

git reset --hard HEADBereitgestellt von

Das verwirft alle Änderungen im Working Directory, inklusive deiner Teillösungen. Nutze es, wenn du alles bereinigen und neu beginnen willst.

Denk daran: Dieser Befehl zerstört nicht eingecheckte Arbeit. Sei sicher, dass du wirklich alles verwerfen willst.

Nach dem Abbruch bleibt dein Stash im Stack (außer pop ist vor den Konflikten vollständig durchgelaufen). Du kannst es später erneut versuchen oder git stash branch für einen saubereren Ansatz nutzen.

Stashes aufräumen

In langlebigen Projekten häufen sich Stashes schnell. Du stashst für einen Bugfix und vergisst es. Du legst experimentelle Stashes an, die du nie poppst. Sechs Monate später hast du 20 Stashes und keine Ahnung, was die Hälfte davon enthält.

Das erschwert es, den wirklich benötigten Stash zu finden. Du läufst git stash show -p über jeden Eintrag, nur um den Inhalt zu erkennen.

Das kostet Zeit. Räum daher regelmäßig auf.

Einzelne Stashes löschen

Mit git stash drop entfernst du einen bestimmten Stash:

git stash drop stash@{2}Bereitgestellt von

Das löscht stash@{2} aus deinem Stack. Die übrigen rücken auf – aus stash@{3} wird stash@{2}.

Du kannst den jüngsten Stash auch ohne Index löschen:

git stash dropBereitgestellt von

Standardmäßig wird stash@{0} entfernt.

Aus meiner Git-Praxis sind dies die Top-Gründe fürs Droppen:

1. Du brauchst die Änderungen nicht mehr
2. Du hast doppelte Stashes (passiert öfter als man denkt)
3. Ein Stash ist so alt, dass du den Zweck vergessen hast

Wenn du unsicher bist, inspiziere vorher mit git stash show -p. Lieber einmal mehr prüfen als hinterher mühsam retten.

Den gesamten Stash-Stack leeren

Mit git stash clear löschst du alle Stashes auf einmal:

git stash clearBereitgestellt von

Denk daran: Das ist endgültig. Du kannst es nicht rückgängig machen oder Stashes wiederherstellen.

Nutze git stash clear nur, wenn du sicher bist, dass du keinen Stash mehr brauchst.

Meistens ist es besser, einzeln zu droppen, um nichts versehentlich zu löschen.

Branches aus Stashes erstellen

Manchmal ist es am saubersten, einen Stash in einen eigenen Branch zu verwandeln. So vermeidest du Merge-Konflikte und gibst der Arbeit ein richtiges Zuhause.

git stash branch verwenden

Der Befehl git stash branch erstellt einen neuen Branch und wendet deinen Stash darauf an:

Das passiert dabei:

1. Git erstellt einen neuen Branch feature-experiment von dem Commit, an dem du gestasht hast

2. Git checkt diesen Branch aus

3. Git poppt den Stash auf den Branch

4. Git entfernt den Stash aus deinem Stack (wie bei pop)

Da der Branch vom exakt gleichen Commit startet, gibt es keine Konflikte. Die Änderungen werden immer sauber angewendet.

Du kannst auch einen bestimmten Stash statt des jüngsten verwenden:

git stash branch new-feature stash@{2}Bereitgestellt von

Typische Anwendungsfälle

Einen Branch aus einem Stash zu erstellen, ist perfekt für Experimente. Sagen wir, du hast vor einer Woche experimentellen Code gestasht und willst ihn jetzt ordentlich weiterentwickeln, ohne deine aktuelle Arbeit zu vermischen.

Du bekommst einen sauberen Branch für das Experiment. Wenn es klappt, mergst du zurück. Wenn nicht, löschst du den Branch und gut ist.

Auch für lange Rebases ist das klasse. Statt potenzielle Konflikte während des Rebase zu managen, stashst du alles und erstellst daraus einen Branch.

git stash push -m "WIP before rebase"
git rebase main
git stash branch temp-workBereitgestellt von

So kannst du die gestashten Änderungen separat prüfen und nach dem Rebase sauber integrieren.

Hilfreich ist das auch, um große oder unübersichtliche Änderungen zu isolieren. Stell dir einen massiven Stash mit Änderungen in 15 Dateien vor, von denen die Hälfte mit deinem aktuellen Branch kollidiert. Erstelle einfach einen neuen Branch – kein Durchkämpfen nötig.

Du bekommst einen dedizierten Branch, in dem du alles in Ruhe sichtest, sauber committest und mit klarer History zurück mergst.

Fortgeschrittene Techniken und Rettungsoptionen

Jetzt kennst du die Basics von git stash, daher zeige ich dir ein paar fortgeschrittene Konzepte.

Mit konkreten Stash-Einträgen arbeiten

Du kannst jeden Stash im Stack poppen oder anwenden, nicht nur den jüngsten.

Referenziere sie per Index, um genau das zu holen, was du brauchst:

git stash pop stash@{3}
git stash apply stash@{1}Bereitgestellt von

So holst du ältere Stashes, ohne die jüngeren anzufassen. Wenn du einen mittleren Stash poppst, rücken alle Indizes darunter auf. Aus stash@{4} wird stash@{3} usw. Wenn du Git-Aktionen skriptest oder mehrere Stashes nacheinander poppst, zerschießt die Index-Verschiebung deine Befehle.

Die Lösung: Nutze apply statt pop, wenn du stabile Indizes brauchst:

git stash apply stash@{2}

# Manuell droppen, wenn du fertig bist
git stash drop stash@{2}Bereitgestellt von

So behältst du die volle Kontrolle, wann sich der Stack ändert. Du wendest an, prüfst das Ergebnis und droppst erst dann. Indizes verschieben sich nur, wenn du es ausdrücklich anstößt.

Gestagten Zustand wiederherstellen

Standardmäßig stellen git stash pop und git stash apply zwar deine Änderungen her, aber nicht, was zuvor gestagt war.

Angenommen, du hast drei Dateien geändert und zwei davon vor dem Stash für den Commit gestagt. Beim Pop kommen alle drei als ungestagte Änderungen zurück. Git vergisst, was du committen wolltest.

Die Lösung ist das --index-Flag, um den Staging-Zustand exakt wiederherzustellen:

git stash pop --indexBereitgestellt von

So bekommst du Working Tree und Index exakt wie vor dem Stash zurück. Gestagte Dateien bleiben gestagt, ungestagte bleiben ungestagt.

Du brauchst das Flag, wenn:

1. Du gerade einen sorgfältig zusammengestellten Commit vorbereitest und die Staging-Informationen nicht verlieren darfst

2. Du mit komplexem Staging arbeitest, z. B. wenn du mit git add -p nur bestimmte Hunks gestagt hast

3. Dein Working Directory exakt wie vor dem Stash aussehen soll – ohne Ausnahmen

Meist brauchst du das Flag nicht. Du poppst, siehst dir die Änderungen an und stagst, was nötig ist.

Aus Stash-Fehlern retten

Früher oder später droppst du einen benötigten Stash oder leerst den gesamten Stack versehentlich.

Wenn das passiert, kann dir die Reflog helfen.

Die Reflog zeichnet jede Referenzänderung im Repository auf, auch Stashes. Beim Erstellen oder Droppen eines Stashs wird das protokolliert. Selbst nach dem Droppen existieren die Commits noch eine Weile als unerreichbare Objekte.

Du findest deinen verlorenen Stash, indem du nach unerreichbaren Commits suchst:

git fsck --unreachable | grep commitBereitgestellt von

Jetzt kannst du jeden Commit prüfen, um deinen Stash zu finden:

git show 066ded985342e585bc8e75c074add99ec1950f50Bereitgestellt von

Sieh dir Diff und Commit-Message an, um den gesuchten Stash zu identifizieren. Sobald du ihn gefunden hast, stell ihn wieder her:

git stash apply 066ded985342e585bc8e75c074add99ec1950f50Bereitgestellt von

Damit wendest du den verlorenen Stash auf dein Working Directory an, als wäre er nie gedroppt worden.

Noch besser: Vermeide Fehler von vornherein mit diesen Best Practices:

1. Schreibe beschreibende Stash-Nachrichten, damit du weißt, was du droppst. "Login-Bug fixen" ist hilfreicher als "WIP", wenn du fünf Stashes vor dir hast.

2. Nutze vor dem Droppen git stash show -p zur Bestätigung. Fünf Sekunden prüfen spart fünf Minuten Rettung.

3. Halte deinen Stash-Stack schlank. Drei relevante Stashes sind leichter zu navigieren als 15 alte Einträge.

4. Nutze apply statt pop, wenn du nicht zu 100% sicher bist, dass der Stash weg kann. Droppen kannst du später immer noch.

Reflog-Rettung funktioniert, ist aber mühsam. Schau dir nur das Bild oben an – so viele Commits müsste ich manuell prüfen, und das ist ein kleines Projekt nur für diesen Artikel.

Best Practices und Workflow-Leitlinien

Wer Stashes gut nutzt, folgt Mustern, die Fehler verhindern und den Workflow sauber halten. So gehe ich vor.

Empfohlene Workflow-Muster

Der sicherste Stash-Workflow ist simpel: Mit Nachricht stashen, Kontext wechseln, dann poppen, wenn es weitergeht.

# Arbeit auf feature-branch
git stash push -m "Feature work in progress"

git checkout main
# Dringende Arbeit auf main

# Zurück
git checkout feature-branch
git stash popBereitgestellt von

Das deckt die meisten Situationen ab. Du bewahrst Arbeit, erledigst die Unterbrechung und stellst alles sauber wieder her.

Ein weiteres Muster ist "prüfen vor dem Pop". Du listest, untersuchst den Inhalt und poppst den richtigen Stash.

git stash list
git stash show -p stash@{1}
git stash pop stash@{1}Bereitgestellt von

Dieser zusätzliche Check verhindert, dass du den falschen Stash poppst oder veraltete Arbeit anwendest.

Manche bevorzugen die "zurückhaltende Commit"-Alternative zum Stashen. Statt zu stashen, machen sie einen temporären Commit mit einer Nachricht wie "WIP – not ready" und ändern oder resetten ihn später. Das ist okay, wenn dir Stashes nicht liegen oder du die Arbeit im Verlauf sehen willst. Nachteil: Wenn du das Aufräumen vergisst, wird die Commit-Historie unordentlich.

Integration mit Entwicklungstools

Die meisten Git-GUIs zeigen Stashes visuell an und lassen dich sie mit einem Klick poppen oder anwenden.

Tools wie GitKraken, Sourcetree und GitHub Desktop listen Stashes in der Seitenleiste. Du siehst Nachrichten, inspizierst Diffs und kannst anwenden oder droppen – ohne Befehle zu tippen. Praktisch, wenn du viele Stashes vergleichen willst.

Die Git-Erweiterung von VS Code zeigt Stashes im Source-Control-Panel. Rechtsklick genügt zum Poppen, Anwenden oder Droppen – direkt im Editor.

Shell-Aliasse machen Stashing auf der Kommandozeile schneller. Ergänze sie in deiner .bashrc oder .zshrc:

alias gst='git stash'
alias gstp='git stash pop'
alias gstl='git stash list'
alias gsts='git stash show -p'Bereitgestellt von

Jetzt stashst du mit gst, gstp poppt, gstl listet und gsts zeigt das Diff. Das spart jedes Mal Tastenanschläge.

Stash-Hygiene und Team-Aspekte

Stashes sind lokal – sie werden nie ins Remote-Repository gepusht.

Das heißt: Teamkolleginnen und -kollegen sehen deine Stashes nicht, und du kannst sie nicht von einem anderen Rechner aus nutzen. Wenn du Arbeit teilen willst, stash sie nicht. Nutze Patches oder temporäre Branches.

Um Arbeit per Patch zu teilen, führe Folgendes aus:

git stash show -p > my-work.patch
# Sende die Patch-Datei an dein Team
# Anwendung bei ihnen: git apply my-work.patchBereitgestellt von

Sende die Patch-Datei an dein Team. Sie wenden sie mit git apply my-work.patch an.

Um Arbeit über temporäre Branches zu teilen, nutze:

git checkout -b temp/work-in-progress
git add .
git commit -m "WIP - authentication feature"
git push origin temp/work-in-progressBereitgestellt von

Dein Team kann den Branch pullen, die Arbeit prüfen und weiterführen.

Egal, welchen Ansatz du wählst: Halte gute Stash-Hygiene. Das verhindert Verwirrung und hält deinen lokalen Stack überschaubar. Das sind gute Regeln:

1. Nutze aussagekräftige Namen für jeden Stash. "User-Auth-Logik hinzufügen" sagt, was drin ist. "WIP on feature-branch" sagt nichts.

2. Räume wöchentlich auf. Führe git stash list aus und droppe alles, was älter als eine Woche ist. Wenn du es sieben Tage nicht brauchtest, brauchst du es vermutlich gar nicht.

3. Lass deinen Stash-Zähler nicht über fünf steigen. Mehr als fünf bedeutet, du nutzt Stashes als Langzeitspeicher statt als temporäre Ablage. Popp sie, committe die Arbeit oder droppe sie.

4. Wenn im Team jemand fragt: "Wo ist der Code, an dem du gearbeitet hast?", antworte niemals: "In meinem Stash." Stashes sind privat und temporär – nicht zum Teilen oder Archivieren wichtiger Arbeit.

Fazit

Du weißt jetzt, wie git stash pop funktioniert und wann du es nutzen solltest.

Im Kern ist Stashing einfach: Nicht eingecheckte Arbeit sichern, den Kontext wechseln und später wiederherstellen. Aber die Details zählen. Zu wissen, wann pop oder apply sinnvoll ist, wie man Konflikte löst und wann man Branches aus Stashes erstellt, spart dir viel Frust.

Wichtigste Erkenntnis: Stashes sind temporär, keine dauerhaften Backups. Schreib klare Nachrichten, räume regelmäßig auf und lass den Stack nicht über fünf Einträge wachsen. Willst du Arbeit teilen oder langfristig behalten, committe sie in einen Branch.

Wenn dir dieser Artikel gefallen hat und du Git verbessern möchtest, sind unsere Kurse Intermediate Git und Intermediate GitHub Concepts die nächsten guten Anlaufstellen.