Übersicht
git restore [--staged] [--source=<tree>] [-p] <pathspec>...Beschreibung
Der git restore-Befehl, eingeführt in Git 2.23, ersetzt die Datei-Wiederherstellungs-Hälfte von git checkout. Er ist zweckgebaut für zwei Fälle: Verwerfen von ungestagten Änderungen im Working Tree (Standardverhalten) und Unstagen von Änderungen aus dem Index (mit --staged). Die saubere Trennung macht das Werkzeug fehleranfälliger als git checkout.
Sie können aus jeder Quelle wiederherstellen: einem anderen Commit, Branch oder Tag. Kombiniert mit -p können Sie interaktiv auswählen, welche Hunks wiederhergestellt werden. git restore modifiziert nie Branches oder HEAD — es berührt nur Dateien.
Im täglichen Einsatz integriert sich git restore eng mit Shell-Aliasen, Editor-Plugins und Continuous Integration. Power-User fügen oft Aliase hinzu, die Flags kombinieren, die sie immer übergeben, oder wickeln den Befehl in Skripte, die Teamkonventionen durchsetzen. Die Ausgabeformatierung kann über Git-Config angepasst werden — Pretty-Formate, Farbschemata und Pager-Verhalten sind alle einstellbar. Wenn etwas schiefgeht, ist der erste Diagnoseschritt üblicherweise, den Befehl erneut mit GIT_TRACE=1 in der Umgebung auszuführen, was die zugrunde liegenden Plumbing-Aufrufe offenlegt. Für ungewöhnliche Situationen öffnet die --help-Ausgabe (git restore --help) die vollständige Manpage mit Details zu jeder Option, einschließlich solcher, die in alltäglichen Workflows selten verwendet werden, aber für Debugging oder Skripting im großen Maßstab essentiell sind.
Zu verstehen, wie git restore mit dem Rest von Gits Datenmodell interagiert — der Objektdatenbank, dem Index, Refs und dem Working Tree — zahlt sich aus. Jeder Befehl operiert auf einer Teilmenge dieser Stücke, und zu wissen, welche er berührt, hilft Ergebnisse vorherzusagen und sich von Fehlern zu erholen. Das Lesen der offiziellen Git-Dokumentation neben praktischer Übung in einem Wegwerf-Repository ist der schnellste Weg, die Nuancen zu verinnerlichen. Die meisten Produktionsprobleme mit Git rühren von einer von drei Ursachen: überraschendem Standardverhalten, partiellen Netzwerkoperationen oder dem Umschreiben bereits geteilter Historie. Ein funktionierendes mentales Modell der Nebenwirkungen von git restore hilft, alle drei zu vermeiden.
Häufige Optionen
| Option | Beschreibung |
|---|---|
--staged | Stellt den Index statt des Working Trees wieder her (d. h. unstaget). |
--worktree | Stellt den Working Tree wieder her (Standard). |
--source=<tree> / -s | Stellt aus einem bestimmten Commit, Branch oder Tag wieder her. |
-p, --patch | Wählt interaktiv Hunks zur Wiederherstellung aus. |
--ours / --theirs | Stellt während eines Konflikts eine Seite wieder her. |
-q, --quiet | Unterdrückt Fortschrittsausgabe. |
Beispiele
git restore src/main.c
# Ungestagte Änderungen in main.c verwerfen
git restore --staged config.yml
# Eine Datei unstagen (Working-Tree-Änderungen behalten)
git restore --source=HEAD~3 README.md
# README.md zurückbringen, wie es vor 3 Commits war
git restore -p
# Interaktiv Hunks zum Verwerfen auswählenHäufige Fehler
git restore auf einer Datei mit ungespeicherten Änderungen überschreibt sie stillschweigend — es gibt keinen Bestätigungsdialog und kein einfaches Undo. Stashen Sie zuerst, falls unsicher. Anfänger verwechseln manchmal --staged mit git reset --hard; --staged berührt nur den Index und lässt Working-Tree-Bearbeitungen intakt.
Verwandte Befehle
git reset, git checkout, git stash, git revert