So ändern Sie den letzten Commit in Git (Nachricht, Dateien, Autor und Rückgängig)

Führen Sie git commit --amend aus, um das letzte Commit für Ihren aktuellen Zweig zu korrigieren. Wenn nichts bereitgestellt wird, ersetzt Git den Commit durch Ihre aktualisierte Nachricht. Wenn Sie neue Änderungen zuerst bereitstellen, fügt Git diese bereitgestellten Änderungen in den Commit ein und ermöglicht Ihnen, die vorhandene Nachricht mit --no-edit beizubehalten oder sie an Ort und Stelle neu zu schreiben. Bevorzugen Sie einen visuellen Workflow? Aktivieren Sie in GitTree auf macOS, Windows und Linux Vorheriges Commit ändern im Commit-Panel (oder klicken Sie mit der rechten Maustaste auf das oberste Commit im Diagramm und wählen Sie Commit-Nachricht bearbeiten…), um die Nachricht vorab auszufüllen, einzelne Zeilen bereitzustellen oder die Bereitstellung aufzuheben, eine Remote-Branch-Warnung anzuzeigen, bevor der Push-Verlauf neu geschrieben wird, und jederzeit mit einem Klick Rückgängig wiederherzustellen.

Kurzreferenz: Jeder Befehl „git commit --amend“.

Wählen Sie den genauen Befehl aus, der mit dem Fehler in Ihrem letzten Commit übereinstimmt – oder springen Sie zum detaillierten Abschnitt unten, um Randfälle, Hooks, signierte Commits und visuelle Alternativen zu finden.

Was git commit --amend eigentlich unter der Haube macht

Jeder Git-Commit-Hash ist eine kryptografische Prüfsumme (SHA-1 oder SHA-256), die aus fünf Datenelementen berechnet wird: dem Root-Baum-Snapshot, dem/den übergeordneten Commit-Hash(es), dem Autor-Namen/E-Mail-Adresse/Zeitstempel, dem Committer-Namen/E-Mail-Adresse/Zeitstempel und der Commit-Nachricht. Ändern Sie auch nur ein einziges Zeichen in der Nachricht – oder den Zeitstempel des Committers eine Sekunde später – und der resultierende Hash ist völlig anders.

# Before git commit --amend:
A --- B --- C  <-- main (HEAD)

# After git commit --amend:
A --- B --- C' <-- main (HEAD)
       \
        C      (still in git reflog as HEAD@{1} until garbage collection)

Wenn Sie git commit --amend ausführen, nimmt Git alles, was sich derzeit im Staging-Bereich (dem Index) befindet, kombiniert es mit den übergeordneten Zeigern von C (B), schreibt ein neues Commit-Objekt C' und aktualisiert Ihren aktuellen Zweigverweis so, dass er auf C' zeigt. Der ursprüngliche Commit C wird nicht sofort gelöscht: Er bleibt mindestens 30 bis 90 Tage (gc.reflogExpireUnreachable) in Ihrem lokalen Reflog (HEAD@{1}) aufgezeichnet, weshalb eine versehentliche Änderung immer lokal wiederhergestellt werden kann – entweder über git reflog oder über die Tools Rückgängig und Wiederherstellen und Lost & Found von GitTree.

1. Ändern Sie die letzte Commit-Nachricht

Wenn Sie gerade etwas committet haben und sofort einen Tippfehler, eine falsche Jira/GitHub-Issue-Nummer oder ein fehlendes Conventional Commits-Präfix (feat:, fix:, chore:) bemerkt haben, überprüfen Sie zuerst git status, damit Sie wissen, ob irgendetwas gestagt ist.

Übergeben Sie mit -m eine neue einzeilige oder mehrabsatzige Nachricht

Um die Nachricht direkt vom Terminal aus zu ersetzen, ohne einen Editor zu starten, übergeben Sie -m. Sie können mehrere -m-Flags verketten, um eine Betreffzeile und Hauptabsätze zu erstellen:

# Replace the commit subject inline
git commit --amend -m "fix(auth): validate refresh token expiry before rotation"

# Replace both the subject line and body paragraph
git commit --amend \
  -m "fix(auth): validate refresh token expiry before rotation" \
  -m "Prevents expired tokens from issuing a new session when clock skew exceeds 30s."

Bearbeiten Sie die vorhandene Nachricht in Ihrem Texteditor

Wenn Ihr Commit bereits eine detaillierte mehrzeilige Beschreibung, Trailer (Co-authored-by:, Signed-off-by:) oder Issue-Referenzen enthält, die Sie nicht erneut eingeben möchten, führen Sie git commit --amend ohne -m aus:

git commit --amend

Git öffnet Ihr konfiguriertes core.editor (Vim, Nano, VS Code, Zed usw.) mit der aktuellen Commit-Nachricht vorinstalliert. Speichern und schließen Sie die Datei, um den geänderten Commit zu schreiben. Wenn Sie Ihre Meinung ändern, während der Editor geöffnet ist, löschen Sie die gesamte Commit-Nachricht (lassen Sie die Datei leer) und speichern Sie – Git bricht die Änderung mit Aborting commit due to empty commit message ab und lässt HEAD unberührt.

2. Fügen Sie vergessene Dateien oder bestimmte Zeilen zum letzten Commit hinzu

Der häufigste Grund, warum Entwickler nach --amend greifen, ist das Vergessen, eine Datei zu speichern, ein Testgerät bereitzustellen oder den Formatierer vor dem Committen auszuführen. Stellen Sie zuerst die fehlenden Änderungen bereit und ergänzen Sie sie dann mit --no-edit, sodass Git die vorhandene Commit-Nachricht beibehält, ohne einen Editor zu öffnen:

# Stage the forgotten file (or files)
git add src/auth/token-validator.test.ts

# Fold the staged file into the last commit and keep the existing message
git commit --amend --no-edit

Stagen Sie nur bestimmte Zeilen oder Abschnitte, bevor Sie Änderungen vornehmen

Was wäre, wenn Ihr Arbeitsbaum sowohl den dreizeiligen Fix, der zum vorherigen Commit gehört, als auch 40 Zeilen Debug-Protokollierung oder Arbeit für Ihr nächstes Feature enthält? Führen Sie nicht git add . oder git commit -a --amend aus. Stellen Sie stattdessen nur die genauen Hunks oder Zeilen bereit, die zum vorherigen Commit gehören, indem Sie den Patch-Modus verwenden (ausführlich behandelt in unserer Anleitung zu git add -p und dem Staging bestimmter Zeilen):

# Choose y/n/s (split) for each changed hunk
git add -p src/auth/token-validator.ts

# Verify what is staged vs what stays in the working tree
git diff --staged

# Amend the last commit with only the staged hunks
git commit --amend --no-edit

In GitTree müssen Sie sich nie mit der Terminal-Hunk-Aufteilung (s, e) herumschlagen, um dies zu tun: Klicken Sie auf eine beliebige Datei in Nicht bereitgestellte Änderungen, wählen Sie die genauen Zeilen aus oder klicken Sie auf Stage Hunk im Nebeneinander- oder Inline-Diff und schalten Sie Vorheriges Commit ändern um. Sehen Sie sich unseren Git-Diff-Leitfaden an, um zu erfahren, wie die Überprüfung von gestaffelten und nicht gestaffelten Unterschieden verhindert, dass versehentlicher Code in einen geänderten Commit gelangt.

3. Entfernen Sie eine versehentlich übertragene Datei (ohne sie von der Festplatte zu löschen).

Angenommen, Sie haben git add . ausgeführt und versehentlich eine .env.local-Datei, ein großes Build-Artefakt oder eine Datei, die zu einer separaten Pull-Anfrage gehört, committet. Wie Sie es aus HEAD entfernen, hängt davon ab, ob die Datei im Commit vor HEAD (HEAD~1) vorhanden war oder in HEAD neu hinzugefügt wurde.

Fall A: Eine neu hinzugefügte Datei aus dem letzten Commit entfernen (lokale Datei behalten)

Verwenden Sie git rm --cached, um die Datei aus dem Staging-Index zu entfernen, während die physische Datei auf Ihrer Festplatte verbleibt, und ändern Sie dann Folgendes:

# Remove the file from the index only (leaves the file on disk)
git rm --cached .env.local

# Optional: add it to .gitignore so it never gets staged again
echo ".env.local" >> .gitignore
git add .gitignore

# Rewrite the last commit without .env.local
git commit --amend --no-edit

Fall B: Änderungen an einer nachverfolgten Datei beim letzten Commit rückgängig machen (lokale Änderungen beibehalten)

Wenn <file> bereits in HEAD~1 verfolgt wurde und Sie versehentlich Änderungen daran in HEAD eingefügt haben, verwenden Sie nicht git rm --cached (da dies zu einer Dateilöschung in HEAD führen würde!). Stellen Sie stattdessen den Indexeintrag für diese Datei aus HEAD~1 wieder her:

# Reset only the staged index state of <file> back to HEAD~1
git restore --source=HEAD~1 --staged src/config/database.ts

# Amend HEAD: the commit no longer touches database.ts, and your local edits stay in the working tree
git commit --amend --no-edit

Wenn Sie stattdessen unerwünschte lokale Änderungen verwerfen oder nicht verfolgte Dateien vollständig bereinigen möchten, lesen Sie So verwerfen Sie Änderungen und bereinigen nicht verfolgte Dateien in Git und So stellen Sie eine gelöschte Datei in Git wieder her.

4. Ändern Sie den Autor, die E-Mail-Adresse oder den Zeitstempel des letzten Commits

Wenn Sie einen Commit auf einem neuen Laptop durchführen, bevor Sie user.email festlegen, oder einen Commit innerhalb eines Arbeitsrepositorys durchführen, während Ihre persönliche GitHub-E-Mail-Adresse global konfiguriert ist, zeichnet der Commit die falsche Identität auf. git commit --amend kann die Metadaten des Commits neu schreiben, ohne eine einzige Datei zu berühren.

# Option 1: Set an explicit author name and email on the last commit
git commit --amend --author="Jane Doe <jane@company.com>" --no-edit

# Option 2: Update git config first, then reset the commit author to match
git config user.name "Jane Doe"
git config user.email "jane@company.com"
git commit --amend --reset-author --no-edit

# Option 3: Amend the author date as well
git commit --amend --date="2026-11-11T14:30:00+02:00" --no-edit

5. So ändern Sie einen bereits gepushten Commit sicher

Sobald Sie einen Commit ändern, der bereits an origin gepusht wurde, weichen Ihr lokaler Zweig und der Remote-Tracking-Zweig (origin/<branch>) voneinander ab: Ihr lokaler Zweig hat C', während origin immer noch C hat. Beide Commits teilen sich das übergeordnete Element B.

Wenn es sich bei dem Zweig um Ihren eigenen Feature- oder Pull-Request-Zweig handelt, aktualisieren Sie den Remote-Zweig sicher mit --force-with-lease (und --force-if-includes in Git 2.30+):

# Safely replace the remote branch tip with your amended commit
git push --force-with-lease --force-if-includes origin HEAD

• Warum `--force-with-lease` anstelle von `--force`: Einfaches git push --force überschreibt blind den Remote-Zweig und löscht alle Commits, die ein Teamkollege oder CI-Bot seit Ihrem letzten Abruf gepusht hat. --force-with-lease prüft, ob origin/<branch> immer noch auf den genauen Commit-SHA verweist, der in Ihrer lokalen Remote-Tracking-Referenz gespeichert ist; Wenn in der Zwischenzeit jemand anderes gepusht hat, lehnt Git den Push ab, anstatt seine Arbeit zu verlieren.
• Was `--force-if-includes` hinzufügt: Wenn Sie den automatischen Abruf im Hintergrund aktiviert haben, wird Ihre Remote-Tracking-Referenz möglicherweise vor dem Push aktualisiert. --force-if-includes überprüft, ob der Commit an der Spitze des Remote-Zweigs tatsächlich in Ihr lokales Reflog integriert wurde, bevor das Umschreiben zugelassen wurde.
• Wenn Sie sich auf `main` oder einem gemeinsam genutzten Zweig befinden: Ändern Sie nicht einen gemeinsam genutzten Zweig und erzwingen Sie keinen Push-Push, auf dem andere Entwickler ihre Arbeit basieren. Lassen Sie stattdessen den Commit intakt und pushen Sie einen neuen Fix-Commit oder machen Sie ihn mit git revert sauber rückgängig (siehe unsere Anleitung zum Zurücksetzen von Commits und Zusammenführungen und das Tutorial zum Wiederherstellen gepushter Fehler).
• Müssen Sie zuerst Ihren Tracking-Zweig konfigurieren? Siehe So richten Sie einen Upstream-Zweig in Git ein.

6. Was passiert, wenn der Commit, den Sie ändern müssen, NICHT der letzte Commit ist?

git commit --amend schreibt immer nur HEAD neu (das Tipp-Commit). Wenn der Tippfehler oder die fehlende Änderung in HEAD~2 oder drei Commits zurückliegt, haben Sie zwei Möglichkeiten zur Bereinigung – ohne manuelles Stashen und Rosinenpicken:

Option 1: Schneller CLI-Autosquash mit git commit --fixup

Stellen Sie den Fix bereit, erstellen Sie einen --fixup-Commit, der auf den SHA des älteren Commits abzielt (oder --fixup=amend:<sha>, um auch dessen Nachricht zu bearbeiten), und führen Sie git rebase -i --autosquash aus:

# 1. Stage the changes meant for the older commit (e.g. a1b2c3d)
git add src/api/client.ts

# 2. Create a fixup commit targeting a1b2c3d
git commit --fixup=a1b2c3d

# 3. Autosquash the fixup commit straight into a1b2c3d
GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash a1b2c3d~1

Option 2: Visual Interactive Rebase in GitTree

Anstatt SHAs zu kopieren und Rebase-ToDo-Dateien im Terminal zu bearbeiten, lesen Sie unsere vollständige interaktive Rebase-GUI-Anleitung und Branch-Rebase-Anleitung. Klicken Sie im Interactive Rebase- und Reword, Squash and Drop-Planer von GitTree mit der rechten Maustaste auf einen beliebigen älteren Commit im Diagramm, wählen Sie Interactive Rebase from Here…, wechseln Sie diesen Commit zu Reword oder ziehen Sie einen Fix-Commit darauf zu Fixup/Squash und wenden Sie ihn mit einem Klick an.

7. So machen Sie einen versehentlichen Git-Commit --amend rückgängig

Haben Sie git commit --amend ausgeführt, während unbeabsichtigte Dateien bereitgestellt wurden, oder haben Sie versehentlich eine von Ihnen benötigte Commit-Nachricht überschrieben? Da Git jede Bewegung von HEAD im lokalen Reflog aufzeichnet, befindet sich Ihr Commit vor der Änderung immer noch sicher bei HEAD@{1}.

# 1. Inspect the reflog to see the amend and the commit before it
git reflog -n 5
# e9f8d7c (HEAD -> feature) HEAD@{0}: commit (amend): feat: add billing webhook
# 4a3b2c1 HEAD@{1}: commit: feat: add billing webhook

# 2. Restore the branch to the pre-amend commit and keep any extra changes staged
git reset --soft HEAD@{1}

Durch die Verwendung von git reset --soft HEAD@{1} wird Ihr Verzweigungszeiger direkt auf den ursprünglichen Commit (4a3b2c1) zurückgesetzt und die Differenz zwischen dem geänderten Commit und dem ursprünglichen Commit in Ihrem Index belassen – nichts in Ihrem Arbeitsbaum geht verloren. Für einen tieferen Einblick in soft-, mixed- und hard-Resets und Reflog-Wiederherstellung lesen Sie Git Reset --soft vs --mixed vs --hard, wie man Git Reset, Rebase oder Commit mit Reflog rückgängig macht und wie man gelöschte Stashes und baumelnde Commits wiederherstellt.

Wann sollte git commit --amend vs. reset, revert oder rebase -i verwendet werden?

Verwenden Sie diese Entscheidungsmatrix, wann immer Sie den Verlauf korrigieren müssen, damit Sie den Befehl auswählen, der zur Position Ihres Commits passt und ob Teamkollegen ihn gepullt haben:

Wie GitTree jeden häufigen git commit --amend-Fehler beseitigt

Die meisten Unfälle mit Befehlszeilenänderungen passieren, weil das Terminal drei wichtige Kontextteile verbirgt, bis es zu spät ist: was sich bereits in Ihrem Staging-Bereich befindet, ob HEAD bereits auf origin übertragen wurde und was der vorherige Commit-SHA war, bevor Sie ihn überschrieben haben. GitTree löst jeden dieser Fehlermodi direkt in der Schnittstelle:

• Live-gestufte vs. nicht-gestufte Diff-Inspektion: Bevor Sie auf Amend Commit klicken, befindet sich die Liste der gestuften Änderungen direkt über dem Commit-Feld, sodass Sie nie versehentlich halbfertige Dateien in HEAD falten können. Sie können einzelne Zeilen, Hunks oder Dateien mit einem Klick bereitstellen oder die Bereitstellung aufheben (Dateien, Hunks und Zeilen bereitstellen).
• Pushed-Commit-Erkennung und Force-Push-With-Lease-Schutz: Wenn sich HEAD bereits im Remote-Zweig befindet, warnt GitTree Sie direkt im Commit-Panel, *bevor* Sie Änderungen vornehmen, und verknüpft den Workflow mit Push erzwingen (mit Lease)…, sodass Sie niemals den Push eines Teamkollegen überschreiben.
• Rechtsklick-Umformulierung und schnelle `fixup!`/`amend!`-Erstellung: Möchten Sie HEAD umformulieren, ohne Ihre bereitgestellten Dateien zu berühren? Klicken Sie mit der rechten Maustaste auf den obersten Commit im Commit-Diagramm und wählen Sie Commit-Nachricht bearbeiten…. Müssen Sie ein älteres Commit reparieren? Klicken Sie mit der rechten Maustaste auf den älteren Commit im Diagramm, um einen fixup!- oder amend!-Commit zu erstellen, oder öffnen Sie Interactive Rebase.
• Automatische Sicherheits-Snapshots (`refs/ogt/trash`) und Rückgängigmachen mit einem Klick: Vor der Ausführung einer der 19 verlaufsverändernden Vorgänge – einschließlich Ändern eines Commits, interaktivem Rebase, Zurücksetzen, Löschen von Zweigen und Verwerfen – zeichnet GitTree einen lokalen Snapshot unter refs/ogt/trash auf. Wenn Sie auf Rückgängig (Cmd+Z / Ctrl+Z) klicken, wird Ihr exakter Commit- und Staging-Status vor der Änderung sofort wiederhergestellt.
• Visual Lost & Found & integriertes Terminal: Selbst wenn Sie das integrierte Terminal oder vor Wochen geändert haben, ist Lost & Found nicht erreichbar und ersetzt Commits durch ihre vollständigen Diffs, sodass Sie sie wiederherstellen, auswählen oder verzweigen können, ohne die rohe git reflog-Ausgabe zu analysieren.
• Git-Hooks, geheime Warnungen und AI-Commit-Nachrichten: GitTree führt die pre-commit und commit-msg Git-Hooks Ihres Repositorys aus, überprüft bereitgestellte Diffs auf versehentliche API-Schlüssel und lässt (in GitTree Pro) Nour mithilfe Ihres eigenen lokalen Coding-Agenten genaue Commit-Nachrichten generieren.