Wiederherstellungspunkte und Git-Stash
Die Blöcke sind verschiedene Fälle, kein Gesamtskript. Wähle den passenden Fall. Branchnamen, Pfade und VERIFIED_COMMIT vor Nutzung ersetzen. Abbruchbefehle gelten nur für ihre laufende Operation; nicht beide Alternativen ausführen.
Kurzantwort
FluxGit-Wiederherstellungspunkte erfassen Zustände für abgedeckte Historienoperationen. Ein manueller Stash legt lokale Änderungen für später zurück; das ist ein anderer Ablauf.
Beispiel und Voraussetzungen
Tutorial G12 wechselt den Branch mit ausstehenden tracked-Änderungen. Untracked-Dateien bleiben im Verzeichnis, sofern du sie nicht ausdrücklich einbeziehst.
Vor Änderungen prüfen
Prüfe git status --short und git diff. Entscheide vor dem Branchwechsel, was du sichern willst; ein sauberes Verzeichnis ist keine dauerhafte Sicherung.
git status --short
git diffReferenz oder getrennten Checkout behalten
Erstelle einen manuellen Stash mit erkennbarer Nachricht. git stash push speichert tracked-Änderungen; nutze -u nur, um zusätzlich untracked-Dateien einzubeziehen.
git stash push -m "school/manual-before-switch"
git stash listErster Ablauf
Prüfe git stash list und wechsle zum Zielbranch. Bei der Rückkehr prüfst du den Kontext vor dem Anwenden des gewählten Eintrags.
git switch target-branchAnderes Ergebnis bewusst wählen
git stash apply erhält den Eintrag. git stash pop entfernt ihn erst nach erfolgreicher Anwendung; bei einem Konflikt bleibt er erhalten.
git stash show --patch 'stash@{0}'
git stash apply 'stash@{0}'Grenzen und Ausnahmen
Automatische Punkte decken reset, rebase, cherry-pick, revert und merge auf geschützten Ausführungspfaden ab. Discard und clean erzeugen keinen universellen Flux restore point.
Konflikte und Aufräumen
Bei Konflikten prüfst und löst du die Dateien gezielt. Wiederhole pop nicht und lösche den Eintrag nicht, um einen offenen Zustand zu verstecken.
Ergebnis prüfen
Prüfe Dateien, Index und Tests nach der Anwendung. Entferne einen Eintrag erst, wenn die gewünschte Arbeit nachweislich erhalten ist.
git status --short
git diff
git diff --cachedHäufige Fragen
Ein Stash wird nicht automatisch mit Push veröffentlicht und ersetzt keine Sicherung. Die Wiederherstellung benötigt weiterhin den relevanten lokalen Zustand.
Operation in FluxGit prüfen
Safety Timeline vereint Reflog-Bewegungen, Risiken und Wiederherstellungspunkte. Die Punktdaten bleiben lokal; nutze Vorschau und Wiederherstellungskontext der jeweiligen Operation.
Offizielle Git-Referenzen
Git-Branch wechseln mit unfertiger Arbeit: git stash anschaulich
Lege eine versionierte Änderung mit git stash ab, benenne sie, wechsle den Branch und kehre für pop zurück. Erfahre, warum unversionierte Dateien bleiben und wie sich apply von einem erfolgreichen pop unterscheidet. Mit Terminalbefehlen.
Auf YouTube ansehen — öffnet einen neuen Tab
In einem Test-Repository aufgenommen. Englische Vertonung und deutsche Untertitel.
Transkript der Erzählung lesen
- Du bist mitten in einer Änderung und musst jetzt einen anderen Branch ansehen. Sie ist noch nicht bereit für einen Commit, und du willst sie nicht verlieren.
- Hier ist die unfertige Änderung in app.py.
- Ein Stash legt versionierte Änderungen ab. Hier speichert er die Änderung in app.py und entfernt sie aus dem Arbeitsordner. Unversionierte Dateien bleiben auf der Festplatte. Ein erfolgreiches pop stellt die Änderung wieder her und entfernt ihren Stash-Eintrag.
- Wähle Stash current changes und gib einen Namen ein, den du später wiedererkennst.
- Wechsle zum anderen Branch. Die versionierte Änderung liegt im Stash. Die unversionierte Datei bleibt im Ordner.
- Dort fertig. Zurück zu main.
- Wende pop auf den Stash an. Die Änderung ist wieder in app.py, und der Stash ist weg.
- Apply oder pop? Apply stellt die Änderungen wieder her und behält den Stash-Eintrag. Pop entfernt ihn nur, wenn die Änderungen erfolgreich angewendet werden. Bei Konflikten bleibt der Stash erhalten.
- Im Terminal: git stash push mit einer Nachricht, den Branch wechseln und zurückkehren, dann git stash pop.
- Zusammenfassung. Unfertige Arbeit kommt ins Regal, nicht in einen halbfertigen Commit. Nächste Lektion: Commits vor dem Pull Request aufräumen.