git restore

Was git restore bewirkt

Der Befehl git restore kopiert eine saubere Version einer Datei in dein Arbeitsverzeichnis, deinen Staging-Bereich oder beide. Eingeführt in Git 2.23 zusammen mit git switch, übernahm er die dateibezogenen Aufgaben, die früher im überlasteten Befehl git checkout versteckt waren. Seine Aufgabe besteht darin, eine Frage zu beantworten: Woher soll die gute Kopie dieser Datei kommen, und wo soll sie landen?

Um ihn effektiv zu nutzen, hilft es, Gits „drei Bäume" zu kennen: das Arbeitsverzeichnis (die Dateien, die du auf der Festplatte bearbeitest), den Index (auch Staging-Bereich genannt — was git add schreibt und was der nächste Commit erfasst), und HEAD (der Snapshot deines letzten Commits). git restore verschiebt Inhalte immer von einer Quelle in ein Ziel unter diesen. Zwei Flags steuern das:

• --source=<rev> — woher die saubere Kopie kommt. Standardmäßig aus dem Index oder aus HEAD, wenn --staged verwendet wird.
• --staged und/oder --worktree — wohin die Kopie geschrieben wird. Standardmäßig --worktree.

Diese Seite behandelt die alltäglichen Anwendungsfälle: Bearbeitungen verwerfen, Staging rückgängig machen, aus einem älteren Commit wiederherstellen, eine gelöschte Datei wiederherstellen und wie sich restore von reset und revert unterscheidet.

Änderungen im Arbeitsverzeichnis verwerfen

Standardmäßig überschreibt git restore eine Datei in deinem Arbeitsverzeichnis mit der Version aus dem Staging-Bereich (dem Index). Wenn du eine Datei bearbeitet hast und diese Bearbeitungen verwerfen möchtest:

git restore index.html

Die Datei kehrt zu ihrem zuletzt gestagten Zustand zurück (oder zu ihrem HEAD-Zustand, wenn sie noch nie gestagt wurde). Da dies destruktiv ist — deine nicht gestagten Bearbeitungen sind endgültig verloren und können nicht mit git reflog wiederhergestellt werden — gibt Git der Operation bewusst einen klaren, expliziten Namen, anstatt sie hinter checkout zu verstecken.

Um Änderungen in vielen Dateien auf einmal zu verwerfen, übergib ein Verzeichnis oder einen Pathspec. Dies ist einer der wenigen git restore-Befehle, der mit einem einzigen Tastendruck viel Arbeit vernichten kann, also überprüfe zuerst mit git status, was nicht committed ist:

git restore .          # discard all changes in the current directory
git restore src/       # discard all changes under src/

Staging rückgängig machen mit --staged

Um eine Datei aus dem Staging-Bereich zu entfernen, ohne ihren Inhalt auf der Festplatte zu ändern, verwende --staged. Damit wird die Version aus HEAD zurück in den Index kopiert, sodass deine Bearbeitungen im Arbeitsverzeichnis erhalten bleiben:

git restore --staged index.html

Dies ist der moderne Ersatz für git reset HEAD <file> und genau das, was Git in seinem Hinweistext vorschlägt, wenn du git status nach dem Stagen von etwas ausführst:

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   index.html

Aus einem bestimmten Commit wiederherstellen

Die Option --source ermöglicht es dir, den Inhalt einer Datei aus einem beliebigen Commit, Branch oder Tag zu holen — nicht nur aus dem Index oder HEAD:

git restore --source=HEAD~2 config.yml

Damit spulst du eine einzelne Datei zurück auf den Stand von vor zwei Commits. Beachte, was sie nicht tut: Sie erstellt keinen Commit und verschiebt keinen Branch-Zeiger. Der alte Inhalt landet in deinem Arbeitsverzeichnis als gewöhnliche nicht gestagte Änderung, die du selbst inspizieren, stagen und committen kannst. Du kannst genauso einfach einen Branch-Namen (--source=main) oder einen Tag (--source=v1.0) verwenden.

Eine gelöschte Datei wiederherstellen

Wenn du eine getrackte Datei versehentlich löschst und die Löschung noch nicht committet hast, bringt git restore sie aus dem Index oder HEAD zurück:

git restore app.js

Da die Datei noch in einem bekannten guten Snapshot vorhanden ist, schreibt Git sie genau wie vorher auf die Festplatte. (Wenn du die Löschung bereits committet hast, stelle sie stattdessen aus dem Zeitpunkt vor diesem Commit wieder her: git restore --source=HEAD~1 app.js.)

Beide Kopien auf einmal zurücksetzen

Die Kombination von --staged und --worktree setzt eine Datei vollständig zurück — sowohl die gestagte Kopie als auch die Kopie auf der Festplatte — auf HEAD:

git restore --staged --worktree index.html

Dies ist der Befehl „Lass diese Datei genau wie der letzte Commit aussehen, egal was ich gemacht habe". Er verwirft sowohl gestagte als auch nicht gestagte Bearbeitungen in einem einzigen Schritt.

Einen Teil einer Datei wiederherstellen

Wie git add und git checkout unterstützt git restore einen Patch-Modus. Mit -p (oder --patch) führt Git dich durch jeden Änderungs-Hunk und fragt, ob du ihn verwerfen möchtest, sodass du einige Bearbeitungen wegwerfen kannst, während du andere behältst:

git restore -p index.html

Dies ist nützlich, wenn du mehrere unzusammenhängende Änderungen in einer Datei vorgenommen hast und nur ein bestimmtes Experiment rückgängig machen möchtest.

Häufige Optionen

restore vs. reset vs. revert

Diese drei Befehle sind leicht zu verwechseln, da alle etwas „rückgängig machen", aber sie arbeiten auf unterschiedlichen Ebenen:

• git restore arbeitet auf Dateien im Arbeitsverzeichnis und Index. Es verschiebt niemals Branch-Zeiger oder schreibt den Verlauf um.
• git reset verschiebt die aktuelle Branch-Spitze und kann den Staging-Bereich ändern — es arbeitet auf Commit-Ebene.
• git revert erstellt einen neuen Commit, der einen vorherigen rückgängig macht, und lässt den bestehenden Verlauf intakt.

Verwende restore, wenn du einfach möchtest, dass eine Datei so aussieht, wie sie irgendwo anders ausgesehen hat. Wenn du ganze Commits löschen oder einen Branch verschieben möchtest, ist das die Aufgabe von git reset. Wenn die Änderungen bereits gepusht und geteilt sind, verwende git revert, damit du den Verlauf, von dem andere abhängen, nicht umschreibst. Um Änderungen vorübergehend beiseite zu legen, anstatt sie zu verwerfen, siehe git stash.

Übungsaufgaben