Übersicht

git reset [--soft | --mixed | --hard] [<commit>]
git reset [<commit>] [--] <pathspec>...

Beschreibung

Der git reset-Befehl bewegt den aktuellen Branch-Zeiger zu einem festgelegten Commit und aktualisiert optional den Index und Working Tree. Er hat drei Hauptmodi: --soft (nur HEAD bewegen), --mixed (Standard; setzt auch den Index zurück) und --hard (setzt auch den Working Tree zurück und verwirft alle Änderungen).

Reset ist einer der mächtigsten und gefährlichsten Git-Befehle. git reset --hard kann Arbeit dauerhaft verlieren — obwohl git reflog üblicherweise eine Wiederherstellung innerhalb des Reflog-Fensters erlaubt. Mit Pfad-Argumenten operiert reset nur auf dem Index für diese Pfade und bewegt nie HEAD.

Im täglichen Einsatz integriert sich git reset 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 reset --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 reset 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 reset hilft, alle drei zu vermeiden.

Häufige Optionen

Option	Beschreibung
--soft	Bewegt nur HEAD; Index und Working Tree unverändert.
--mixed (Standard)	Bewegt HEAD und setzt den Index zurück; Working Tree unverändert.
--hard	Bewegt HEAD, setzt Index zurück und überschreibt Working Tree.
--keep	Wie --hard, bricht aber ab, falls lokale Änderungen verloren gingen.
--merge	Setzt den Index zurück und aktualisiert Dateien, die zwischen HEAD und Ziel unterschiedlich sind, behält lokale Merges.
-p	Wählt interaktiv Hunks zum Unstagen aus.

Beispiele

git reset HEAD~1
    # Einen Commit zurück; Änderungen im Working Tree behalten

    git reset --soft HEAD~3
    # Die letzten 3 Commits zu einer einzigen gestagten Änderung kombinieren

    git reset --hard origin/main
    # ALLE lokalen Commits und Änderungen verwerfen (gefährlich)

    git reset HEAD config.yml
    # Eine einzelne Datei unstagen (ältere Syntax für git restore --staged)

Häufige Fehler

git reset --hard auf einem Branch mit ungepushten Commits verliert sie. Reflog kann Sie für ~90 Tage retten, aber nur, wenn Sie wissen, wo Sie suchen müssen. git reset HEAD file (unstagen) mit git reset --hard (vernichten) zu verwechseln ist ein klassischer Anfänger-Fußschuss. Modernes Git bietet git restore --staged als klarere Alternative.

Verwandte Befehle

git restore, git revert, git reflog, git stash