git restore

Grundlegende Snapshots

Stellt Dateien im Arbeitsverzeichnis oder im Staging-Bereich wieder her

Der Befehl 'git restore' setzt Dateien auf eine bekannte Version zurück. Standardmäßig überschreibt er eine Arbeitsdatei mit ihrer vorgemerkten Version und verwirft deine Änderungen. Mit --staged nimmt er eine Datei aus dem Staging-Bereich und lässt deine Änderungen auf der Platte. Mit --source holst du eine Datei so zurück, wie sie in einem beliebigen Commit war. Er kam mit Git 2.23, um die Datei-Wiederherstellung von git checkout zu übernehmen.

Syntax

git restore [<options>] [--source=<tree>] [--staged] [--worktree] [--] <pathspec>...
[ ] optional| oder<arg> Platzhalter... wiederholbar--flag Option

Optionen

Klicke auf eine Option, um sie aufzuklappen

Einsteiger (2)

Stellt den Staging-Bereich wieder her: nimmt die Datei aus dem Staging. Deine Arbeitsdatei bleibt unberührt.

EmpfohlenDer sichere Weg aus dem Staging: deine Änderungen bleiben auf der Platte

Beispiel

git restore --staged app.js

Stellt das Arbeitsverzeichnis wieder her (Standard). Zusammen mit --staged werden beide wiederhergestellt.

Bei BedarfStandardziel; mit --staged kombinieren, um beides zurückzusetzen

Beispiel

git restore --staged --worktree app.js

Fortgeschritten (2)

Nimmt die Datei aus dem angegebenen Commit, Branch oder Tag statt aus dem Staging-Bereich.

EmpfohlenEine Datei aus einem beliebigen Commit holen, ohne den Branch zu bewegen

Beispiel

git restore --source=HEAD~1 app.js

Hunks interaktiv auswählen: git fragt bei jeder Änderung nach.

Bei BedarfAusgewählte Hunks verwerfen, den Rest behalten

Beispiel

git restore -p app.js

Die richtige Option wählen

restore im Vergleich zu älteren Befehlen

Dieselben Aktionen, alt und neu

BefehlÄlteres GegenstückWirkung
git restore app.jsgit checkout -- app.jsNicht vorgemerkte Änderungen verwerfen
git restore --staged app.jsgit reset app.jsAus dem Staging nehmen, Änderungen behalten
git restore --source=HEAD~1 app.jsgit checkout HEAD~1 -- app.jsDatei aus einem alten Commit

Beispiele

Änderungen verwerfen

git restore app.js

Verwirft die nicht vorgemerkten Änderungen in app.js.

Eine Datei unstagen

git restore --staged app.js

Nimmt app.js aus dem Staging-Bereich, die Änderungen bleiben.

Datei aus einem alten Commit

git restore --source=HEAD~2 app.js

Holt app.js so, wie es zwei Commits zuvor war.

Workflow-Beispiele

1
git add .

Alles ist vorgemerkt

2
git restore --staged README.md

README.md ist nicht mehr vorgemerkt

3
git commit -m "Add to cart"

Der Commit lässt README.md aus

Fehlerbehebung

error: pathspec 'x' did not match any file(s) known to git

Ursache: Die Datei ist unverfolgt oder der Pfad ist falsch

Prüfe den Pfad mit git status; restore funktioniert nur mit verfolgten Dateien

Ich habe eine Datei wiederhergestellt und meine Änderungen verloren

Ursache: git restore überschreibt die Arbeitsdatei

Nicht gespeicherte Änderungen sind weg; der Rückgängig-Verlauf deines Editors hat sie vielleicht noch. Nächstes Mal zuerst git stash

Tipps & Stolperfallen

Best Practices

  • ✓Führe git diff vor git restore aus, um zu sehen, was du gleich verwirfst.
  • ✓Nutze git restore --staged zum Entfernen aus dem Staging — es rührt deine Änderungen nie an.
  • ✓Bevorzuge git restore gegenüber git checkout für Dateien: der Name sagt, was es tut.

Häufige Fehler

  • ✗git restore <file> auf Änderungen ausführen, die du behalten wolltest — verworfene Änderungen sind nicht wiederherstellbar.
  • ✗Erwarten, dass git restore --staged deine Änderung verwirft: es nimmt sie nur aus dem Staging.
  • ✗git restore nutzen, um einen Commit rückgängig zu machen — es stellt Dateien wieder her; für Commits nutze git reset oder git revert.

FAQ

A:

git restore ändert Dateien. git reset verschiebt den Branch auf einen anderen Commit (und kann auch Dateien zurücksetzen).

A:

Nicht für verworfene Arbeitsänderungen: Git hat sie nie gespeichert. Aus dem Staging nehmen mit --staged verliert nichts.

A:

Git 2.23 oder neuer. In älteren Versionen nutze git checkout -- <file> und git reset <file>.