Commits rückgängig machen: Reset vs. Revert 🔄
Du hast einen oder mehrere Commits gemacht und merkst jetzt, dass etwas schief gelaufen ist – sei es ein Bug, eine falsche Datei oder eine Änderung, die doch nicht so gut war. Git bietet dir verschiedene Möglichkeiten, Commits rückgängig zu machen, aber die richtige Wahl hängt entscheidend davon ab, ob du die Commits bereits gepusht hast oder nicht.
Die entscheidende Frage: Lokal oder schon gepusht?
Bevor du irgendetwas tust, musst du dir eine zentrale Frage stellen:
flowchart TD
START["Commit rueckgaengig machen?"] --> Q1{"Bereits auf GitHub gepusht?"}
Q1 -->|Nein, nur lokal| RESET["git reset verwenden\nHistorie wird umgeschrieben"]
Q1 -->|Ja, bereits gepusht| REVERT["git revert verwenden\nNeuer Gegen-Commit"]
RESET --> R1["Sicher: Du bist der Einzige,\nder diese Commits kennt"]
REVERT --> R2["Sicher: Andere koennen\ndie Aenderung nachvollziehen"]
Diese Unterscheidung ist fundamental wichtig, weil:
- Lokale Commits existieren nur auf deinem Computer – du kannst die Historie nach Belieben ändern, ohne jemanden zu stören.
- Gepushte Commits sind öffentlich – andere könnten sie bereits haben, und wenn du die Historie änderst, erzeugst du Chaos.
Methode 1: git reset – Historie umschreiben
Mit git reset verschiebst du den „Zeiger" deines Branches auf einen früheren Commit. Die Commits, die danach kamen, verschwinden aus der Historie (oder werden zumindest nicht mehr referenziert). Es gibt drei Varianten, die sich darin unterscheiden, was mit deinen Dateiänderungen passiert:
Die drei Reset-Modi
| Modus | Befehl | Was passiert mit den Änderungen? |
|---|---|---|
| Soft | git reset --soft HEAD~1 |
Änderungen bleiben in der Staging Area – bereit für einen neuen Commit |
| Mixed | git reset --mixed HEAD~1 |
Änderungen landen im Working Directory – du kannst sie bearbeiten (Standard) |
| Hard | git reset --hard HEAD~1 |
Änderungen werden komplett gelöscht – unwiederbringlich ⚠️ |
💡
HEAD~1bedeutet „ein Commit vor dem aktuellen". Für zwei Commits zurück:HEAD~2, für drei:HEAD~3, usw.
Wann welchen Modus verwenden?
-
Soft Reset: Du möchtest den letzten Commit „aufbrechen", um ihn anders zu strukturieren oder die Commit-Nachricht zu ändern. Die Änderungen selbst sind in Ordnung.
-
Mixed Reset: Du möchtest den Commit rückgängig machen und die Dateien nochmal überarbeiten, bevor du sie erneut stagst und commitest.
-
Hard Reset: Du möchtest den Commit und alle zugehörigen Änderungen komplett loswerden. Achtung: Das ist nicht rückgängig zu machen!
Reset in PhpStorm durchführen
-
Öffne das Git-Log über Git → Show Git Log oder den Git-Tab am unteren Rand.
-
Finde den Commit, auf den du zurücksetzen möchtest – also den letzten guten Commit, nicht den, den du entfernen willst.
-
Rechtsklick auf diesen Commit und wähle Reset Current Branch to Here…
-
Es erscheint ein Dialog mit den drei Optionen:
- Soft: Behält alle Änderungen in der Staging Area
- Mixed: Behält alle Änderungen im Working Directory (nicht gestagt)
- Hard: Verwirft alle Änderungen unwiderruflich
-
Wähle den passenden Modus und bestätige.
Beispiel: Den letzten Commit rückgängig machen
Du hast gerade einen Commit gemacht, der einen Fehler enthält, aber noch nicht gepusht:
# Im Terminal (alternativ zu PhpStorm):
git reset --mixed HEAD~1
Jetzt ist der Commit weg, aber deine Änderungen sind noch da. Du kannst den Fehler beheben und einen neuen, korrekten Commit erstellen.
Methode 2: git revert – Einen Gegen-Commit erstellen
Im Gegensatz zu reset ändert revert die Historie nicht. Stattdessen erstellt es einen neuen Commit, der die Änderungen eines früheren Commits rückgängig macht. Der ursprüngliche (fehlerhafte) Commit bleibt in der Historie sichtbar – aber seine Auswirkungen werden durch den Revert-Commit aufgehoben.
flowchart LR
A["Commit A\nGrundlage"] --> B["Commit B\nFehlerhaft"]
B --> C["Commit C\nWeitere Arbeit"]
C --> D["Revert B\nMacht B rueckgaengig"]
style B fill:#ffcccc
style D fill:#ccffcc
Warum ist das für gepushte Commits wichtig?
Wenn andere Teammitglieder (oder du selbst auf einem anderen Computer) den fehlerhaften Commit bereits heruntergeladen haben, würde ein reset zu Problemen führen:
- Du änderst die Historie auf GitHub (mit einem sogenannten „Force Push")
- Die anderen haben noch die alte Historie
- Beim nächsten Pull entstehen Konflikte und Verwirrung
Ein revert hingegen fügt einfach einen neuen Commit hinzu – das funktioniert sauber für alle.
Revert in PhpStorm durchführen
-
Öffne das Git-Log und finde den Commit, den du rückgängig machen möchtest.
-
Rechtsklick auf den fehlerhaften Commit und wähle Revert Commit (manchmal auch unter Git → Revert zu finden).
-
PhpStorm erstellt automatisch einen neuen Commit, der alle Änderungen des gewählten Commits umkehrt.
-
Du kannst die Commit-Nachricht anpassen – standardmäßig lautet sie etwas wie „Revert ‚Ursprüngliche Commit-Nachricht'".
-
Nach dem Revert kannst du ganz normal pushen, und alle anderen erhalten die Korrektur sauber über
pull.
Revert im Terminal
# Den letzten Commit reverten:
git revert HEAD
# Einen bestimmten Commit reverten (mit Commit-Hash):
git revert a1b2c3d4
Git öffnet daraufhin einen Editor für die Commit-Nachricht des Revert-Commits.
Mehrere Commits rückgängig machen
Mit Reset (nur lokal!)
Wenn du mehrere aufeinanderfolgende Commits zurücknehmen möchtest und diese noch nicht gepusht sind:
# Die letzten 3 Commits rückgängig machen:
git reset --mixed HEAD~3
In PhpStorm wählst du einfach den Commit aus, auf den du zurücksetzen möchtest – alle Commits danach werden entfernt.
Mit Revert (auch für gepushte Commits)
Hier musst du jeden Commit einzeln reverten, und zwar in umgekehrter Reihenfolge (neueste zuerst):
# Mehrere Commits reverten (neueste zuerst):
git revert HEAD
git revert HEAD~1
git revert HEAD~2
# Oder einen Bereich reverten (erstellt mehrere Revert-Commits):
git revert HEAD~3..HEAD
In PhpStorm führst du den Revert nacheinander für jeden Commit aus, beginnend mit dem neuesten.
Übersicht: Reset vs. Revert
| Aspekt | git reset |
git revert |
|---|---|---|
| Was passiert? | Commits werden aus der Historie entfernt | Neuer Commit macht Änderungen rückgängig |
| Historie | Wird umgeschrieben | Bleibt intakt, wird erweitert |
| Gepushte Commits? | ⚠️ Nur mit Force Push – gefährlich! | ✅ Sicher, normaler Push |
| Teamarbeit | Verursacht Probleme bei anderen | Funktioniert sauber für alle |
| Sichtbarkeit | Fehler wird unsichtbar | Fehler bleibt sichtbar (mit Korrektur) |
| Anwendungsfall | Lokale Korrekturen, bevor jemand die Commits sieht | Korrekturen an öffentlicher/gepushter Historie |
Das gefährliche Terrain: Force Push ⚠️
Es ist technisch möglich, auch nach einem Push die Historie zu ändern – mit einem sogenannten Force Push:
# Nach einem lokalen Reset:
git push --force
# oder etwas sicherer:
git push --force-with-lease
Das solltest du aber nur tun, wenn:
- Du alleine am Repository arbeitest
- Du absolut sicher bist, dass niemand anderes die Commits bereits hat
- Du weißt, was du tust
⚠️ Warnung: Ein Force Push kann die Arbeit anderer unwiederbringlich zerstören, wenn sie auf den gelöschten Commits aufgebaut haben. In den meisten Team-Situationen ist
revertdie bessere Wahl.
Praktische Entscheidungshilfe
Hier eine Zusammenfassung, die dir bei der Entscheidung hilft:
flowchart TD
START["Commit rueckgaengig machen"] --> Q1{"Schon gepusht?"}
Q1 -->|Nein| Q2{"Was soll mit den\nAenderungen passieren?"}
Q2 -->|Behalten und bearbeiten| MIXED["reset --mixed"]
Q2 -->|Behalten und direkt neu committen| SOFT["reset --soft"]
Q2 -->|Komplett verwerfen| HARD["reset --hard"]
Q1 -->|Ja| Q3{"Arbeitest du alleine\nam Repository?"}
Q3 -->|Ja, ganz sicher| Q4{"Soll der Fehler\nsichtbar bleiben?"}
Q3 -->|Nein oder unsicher| REVERT1["revert verwenden"]
Q4 -->|Nein| FORCE["reset + force push\nmit Vorsicht!"]
Q4 -->|Ja oder egal| REVERT2["revert verwenden"]
Zusammenfassung
-
Noch nicht gepusht? → Nutze
git reset– du hast volle Kontrolle über deine lokale Historie und kannst sie nach Belieben ändern. -
Bereits gepusht? → Nutze
git revert– es ist sicher, transparent und funktioniert für alle, die das Repository nutzen. -
Force Push ist ein Werkzeug für Experten und Solo-Projekte – in Teamumgebungen solltest du die Finger davon lassen.
Das Wichtigste ist: Git verliert selten wirklich Daten. Selbst nach einem harten Reset kannst du mit git reflog oft noch auf die „verlorenen" Commits zugreifen – aber das ist ein fortgeschrittenes Thema für einen anderen Tag. 😊