git reset
Den aktuellen HEAD auf den angegebenen Zustand zurücksetzen
Der Befehl 'git reset' macht Änderungen rückgängig, indem er den HEAD des aktuellen Branches auf einen bestimmten Commit verschiebt. Er hat drei Hauptmodi: --soft (Änderungen bleiben gestagt), --mixed (Standard – Änderungen bleiben im Arbeitsverzeichnis) und --hard (verwirft alle Änderungen). Der Befehl ist zentral, um Commits rückgängig zu machen, Dateien zu unstagen und deine Commit-Historie zu verwalten. Vorsicht mit 'git reset --hard', das Änderungen endgültig verwirft.
Syntax
git reset [-q] [<tree-ish>] [--] <pathspec>...
git reset [-q] [--pathspec-from-file=<file>] [<tree-ish>]
git reset (--patch | -p) [<tree-ish>] [--] [<pathspec>...]
git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]Optionen
Die richtige Option wählen
Reset-Modi: Was bleibt erhalten?
Die drei Hauptmodi von reset verstehen und was mit deinen Änderungen passiert
| Befehl | HEAD bewegt sich | Staging-Bereich | Arbeitsverzeichnis | Nutzen, wenn |
|---|---|---|---|---|
--soft | Ja | Erhalten (gestagt) | Erhalten | Commit rückgängig machen, mit Änderungen neu committen |
--mixed (default) | Ja | Geleert (ungestagt) | Erhalten | Commit rückgängig machen, vor dem Stagen bearbeiten |
--hard | Ja | Geleert | Verfolgte Änderungen VERLOREN (unverfolgte bleiben) | Commit und alle Änderungen komplett verwerfen |
Reset, Revert oder Checkout
Den passenden Rückgängig-Befehl für deine Lage wählen
| Befehl | Ändert Historie? | Sicher bei gepushten Commits? | Am besten für |
|---|---|---|---|
git reset | Ja (verschiebt den Branch) | Nein – macht Probleme | Lokale, noch nicht gepushte Commits rückgängig machen |
git revert | Nein (fügt neuen Commit hinzu) | Ja – sicher auf geteilten Branches | Gepushte Commits auf geteilten Branches rückgängig machen |
git checkout -- file | No | Ja | Nicht committete Änderungen an bestimmten Dateien verwerfen |
Änderungen unstagen: reset oder restore
Modernes Git bietet git restore als Alternative zu reset fürs Unstagen
| Befehl | Zweck | Betrifft Commits? | Empfohlen |
|---|---|---|---|
git reset HEAD file | Eine Datei unstagen | No | Klassischer Weg |
git restore --staged file | Eine Datei unstagen | No | Moderner Weg (Git 2.23+) |
git reset | Alle Dateien unstagen | No | Funktioniert gut |
git restore --staged . | Alle Dateien unstagen | No | Klarere Absicht |
Fortgeschrittene Reset-Modi
Wann --merge und --keep statt --hard
| Befehl | Behält lokale Änderungen? | Bricht bei Konflikten ab? | Anwendungsfall |
|---|---|---|---|
--hard | Nein – zerstört alles | No | Vollständiger Reset, Änderungen egal |
--merge | Nur ungestagte Änderungen (gestagte gehen verloren) | Ja | Einen Merge abbrechen und unabhängige Arbeit behalten |
--keep | Ja (in Dateien, die der Reset nicht berührt) | Ja | Commit rückgängig machen, aber unabhängige lokale Änderungen behalten |
Beispiele
Letzten Commit rückgängig machen, Änderungen gestagt behalten
git reset --soft HEAD~1Setzt HEAD einen Commit zurück. Die Änderungen dieses Commits bleiben gestagt und können neu committet werden.
Letzten Commit rückgängig machen, Änderungen im Arbeitsverzeichnis behalten
git reset HEAD~1Standardmodus (--mixed). Setzt HEAD einen Commit zurück. Die Änderungen bleiben erhalten, sind aber ungestagt.
Letzten Commit und Änderungen komplett verwerfen
git reset --hard HEAD~1Setzt HEAD einen Commit zurück und verwirft ALLE nicht committeten Änderungen an verfolgten Dateien. Mit Vorsicht nutzen – verlorene, nicht committete Arbeit ist nicht wiederherstellbar (der Commit selbst bleibt im git reflog).
Eine bestimmte Datei unstagen
git reset HEAD file.jsEntfernt file.js aus dem Staging-Bereich, ohne die Änderungen zu verwerfen. Die Datei bleibt im Arbeitsverzeichnis geändert.
Workflow-Beispiele
git log --oneline -3Letzte Commits ansehen, um zu bestätigen, welcher rückgängig gemacht wird
git reset --soft HEAD~1Commit rückgängig machen, Änderungen gestagt behalten
git statusPrüfen, dass die Änderungen gestagt sind
git commit -m "Better message"Mit neuer Nachricht erneut committen
git statusSehen, was gerade gestagt ist
git reset HEAD unwanted-file.jsBestimmte Datei(en) unstagen
git statusBestätigen, dass die Datei nicht mehr gestagt ist
git commitNur die gewünschten Dateien committen
git statusPrüfen, was verloren geht
git stash(Optional) Änderungen sicherheitshalber stashen
git reset --hard HEAD~1Letzten Commit UND alle verfolgten Änderungen verwerfen (unverfolgte Dateien bleiben)
git statusBestätigen, dass das Arbeitsverzeichnis sauber ist
git reflogDen Commit-Hash vor dem Reset finden
git reset --hard abc1234Auf diesen Commit-Hash zurücksetzen
git log --onelinePrüfen, dass die Commits wiederhergestellt sind
Fehlerbehebung
fatal: ambiguous argument 'HEAD~1': unknown revision
Ursache: Du bist auf dem ersten Commit – es gibt keinen vorigen Commit zum Zurücksetzen
Prüfe git log. Gibt es nur einen Commit, kannst du nicht weiter zurück. Mit git update-ref -d HEAD fängst du ganz neu an.
error: Entry 'app.js' not uptodate. Cannot merge.
Ursache: Eine Datei, die --merge oder --keep ändern müsste, hat nicht committete lokale Änderungen, also wird der Reset abgebrochen
Committe oder stashe deine Änderungen zuerst, oder nutze --hard, wenn du sie verwerfen willst
Versehentlich --hard genutzt und Änderungen verloren
Ursache: Ein Hard-Reset verwirft alle nicht committete Arbeit endgültig
Waren die Änderungen vorher committet: mit git reflog den Commit finden, dann git reset --hard <hash>. Waren sie nie committet: vermutlich für immer verloren.
Reset hat geklappt, aber ein Kollege sagt, die Historie ist kaputt
Ursache: Du hast Commits zurückgesetzt, die schon auf einen geteilten Branch gepusht waren
Nutze auf geteilten Branches git revert. Zum Reparieren: git reflog, den ursprünglichen Commit finden, darauf zurücksetzen, force-pushen (mit dem Team absprechen).
fatal: ambiguous argument 'HEAD' bei git reset HEAD file
Ursache: Das Repository hat noch keine Commits, also existiert HEAD nicht (oder der Pfad ist falsch)
Lass HEAD weg: git reset file.js (oder git rm --cached file.js). Prüfe den genauen Pfad mit git status.
Tipps & Stolperfallen
Best Practices
- ✓Nutze git reset nie auf Commits, die auf geteilte Branches gepusht wurden – nutze stattdessen git revert
- ✓Führe vor einem Reset immer git status aus, um zu verstehen, was betroffen ist
- ✓Nutze --soft, wenn du einen Commit mit Änderungen neu machen willst
- ✓Nutze git stash vor einem Reset mit --hard, falls du deine Änderungen vielleicht zurückwillst
- ✓Denk daran: git reflog rettet die meisten Reset-Fehler (bei committeten Änderungen)
- ✓Nutze git reset HEAD <file>, um Dateien zu unstagen, statt ganze Commits zurückzusetzen
- ✓Nutze eventuell git restore --staged als moderne Alternative zum Unstagen von Dateien
Häufige Fehler
- ✗'git reset --hard' nutzen, ohne zu merken, dass es nicht committete Änderungen endgültig löscht. Prüfe vor --hard immer doppelt.
- ✗Commits zurücksetzen, die schon auf ein geteiltes Remote gepusht wurden. Das schreibt die Historie um und macht Mitwirkenden Probleme. Nutze stattdessen 'git revert'.
- ✗'git reset' mit 'git revert' verwechseln. Reset schiebt den Branch-Zeiger zurück; revert erzeugt einen neuen Commit, der Änderungen rückgängig macht.
- ✗Nicht wissen, dass man sich von einem schlechten Reset mit 'git reflog' erholen kann, um den vorigen Commit-Hash zu finden.
- ✗'git reset --hard HEAD' nutzen, um Arbeitsänderungen zu verwerfen, obwohl 'git checkout -- .' oder 'git restore .' passender wären.
FAQ
Soft behält Änderungen gestagt. Mixed (Standard) behält sie im Arbeitsverzeichnis, aber ungestagt. Hard verwirft alles. Merke: soft = nur Commit rückgängig, mixed = Commit rückgängig + unstagen, hard = alles rückgängig.
Bei committeten Änderungen: ja, finde mit git reflog den ursprünglichen Commit-Hash und setze darauf zurück. Bei nicht committeten Änderungen, die --hard verworfen hat: meist nein, die sind endgültig weg.
HEAD~1 bedeutet „ein Commit vor HEAD“. HEAD~2 ist zwei Commits zurück usw. Du kannst auch direkt Commit-Hashes nutzen, etwa git reset abc1234.
Reset für lokale, noch nicht gepushte Commits – es schreibt die Historie sauber um. Revert für gepushte Commits auf geteilten Branches – es erzeugt einen neuen Commit, der Änderungen rückgängig macht, ohne die Historie umzuschreiben.
Nutze git reset HEAD filename, um eine bestimmte Datei zu unstagen. HEAD bewegt sich nicht und kein Commit ist betroffen – die Datei wird nur aus dem Staging-Bereich entfernt.
Es löscht nicht committete Änderungen endgültig. Anders als committete Änderungen (über das Reflog wiederherstellbar) lässt sich nie committete Arbeit nach einem Hard-Reset nicht zurückholen.