git commit
Änderungen im Repository festhalten
Der Befehl 'git commit' erzeugt einen neuen Commit mit dem aktuellen Inhalt des Index (Staging-Bereich) und einer Nachricht, die die Änderungen beschreibt. Der neue Commit ist ein direktes Kind von HEAD und wird die neue Spitze des aktuellen Branches. Jeder Commit ist ein dauerhafter Snapshot in der Projekthistorie, den man jederzeit wieder ansehen, vergleichen oder wiederherstellen kann.
Syntax
git commit [-a] [-m <msg>] [--amend] [--no-edit] [-v] [-n] [--dry-run] [-s] [-S] [--] [<pathspec>...]Optionen
Die richtige Option wählen
Nachrichten-Optionen
Verschiedene Wege, die Commit-Nachricht anzugeben oder zu bearbeiten
| Befehl | Quelle | Öffnet Editor | Anwendungsfall |
|---|---|---|---|
git commit -m "msg" | In der Zeile | ✗ | Schnelle Commits mit kurzen Nachrichten |
git commit -F file | Datei | ✗ | Vorgeschriebene Nachricht aus einer Datei |
git commit -t file | Vorlage | ✓ | Mit einer Vorlage im Editor beginnen |
git commit -e | Editor | ✓ | Editor auch mit -m erzwingen |
git commit -C <commit> | Kopieren | ✗ | Nachricht eines anderen Commits wiederverwenden |
git commit -c <commit> | Kopieren + Bearbeiten | ✓ | Nachricht eines anderen Commits bearbeiten |
Bereinigen der Nachricht
Wie die Commit-Nachricht vor dem Speichern verarbeitet wird
| Befehl | Modus | Entfernt Kommentare | Entfernt Leerraum | Am besten für |
|---|---|---|---|---|
--cleanup=strip | strip | ✓ | ✓ | Die meisten Commits |
--cleanup=whitespace | Leerraum | ✗ | ✓ | #-Kommentare behalten |
--cleanup=verbatim | Wörtlich | ✗ | ✗ | Nachricht exakt erhalten |
--cleanup=scissors | Schere | Nur unterhalb der Scheren-Zeile | ✓ | #-Zeilen beim Editor behalten |
Autor und Datum
Überschreiben, wer den Commit gemacht hat und wann
| Befehl | Überschreibt | Format | Typische Nutzung |
|---|---|---|---|
--author="Name <email>" | Autor | Name <email> | Im Namen einer anderen Person committen |
--date="date" | Autorendatum | ISO 8601 / relativ | Commits rückdatieren |
--reset-author | Beide | Aktueller Nutzer/aktuelle Zeit | Einen angewendeten Patch übernehmen |
Amend und Historie korrigieren
Optionen zum Ändern vorhandener Commits
| Befehl | Erzeugt | Ändert HEAD | Zu nutzen mit |
|---|---|---|---|
git commit --amend | Ersatz | ✓ | Nachricht oder Inhalt des letzten Commits korrigieren |
git commit --fixup=<sha> | fixup!-Commit | ✗ | git rebase -i --autosquash |
git commit --squash=<sha> | squash!-Commit | ✗ | git rebase -i --autosquash |
Was committet wird
Steuern, welche Dateien in den Commit kommen
| Befehl | Stagt vorher | Commits | Arbeitsverzeichnis |
|---|---|---|---|
git commit | ✗ | Nur Gestagtes | Unverändert |
git commit -a | Verfolgte Dateien | Alle verfolgten | Unverändert |
git commit -i <file> | Angegebene | Gestagtes + Datei | Unverändert |
git commit -o <file> | Nur angegebene | Nur die Datei | Andere gestagte ausgeschlossen |
git commit -p | Interaktiv | Ausgewählte Hunks | Unverändert |
GPG-Signatur
Commits kryptografisch signieren, damit sie überprüfbar sind
| Befehl | Aktion | Verwendeter Schlüssel | Wann verwenden |
|---|---|---|---|
git commit -S | Signieren | Standard-GPG-Schlüssel | Echtheit von Commits nachweisen |
git commit -S<keyid> | Signieren | Bestimmter Schlüssel | Anderen Signaturschlüssel nutzen |
git commit --no-gpg-sign | Nicht signieren | Keine | commit.gpgSign=true übergehen |
Hook-Steuerung
pre-commit- und post-commit-Hooks umgehen oder steuern
| Befehl | Überspringt | Risiko | Wann verwenden |
|---|---|---|---|
git commit --no-verify | pre-commit + commit-msg | Mittel | Notfall-Fix, Hooks später reparieren |
git commit --no-post-rewrite | post-rewrite | Niedrig | Langsame Nachbearbeitung nach dem Amend überspringen |
Dry-Run und Ausgabeformat
Vorschau, was committet würde, ohne zu committen
| Befehl | Format | Maschinenlesbar | Zeigt |
|---|---|---|---|
--dry-run | Lang (Standard) | ✗ | Vollständiger Status mit Hinweisen |
--dry-run --short | Kurz | ✓ | Kompakte Statuscodes |
--dry-run --porcelain | Porcelain | ✓ | Stabiles Format für Skripte |
--dry-run --branch | Mit Branch | ✓ | Ergänzt die Kurzform um Tracking-Infos |
--dry-run -z | NUL-getrennt | ✓ | Sicher bei besonderen Dateinamen |
Statusanzeige im Editor
Steuern, was beim Schreiben der Nachricht im Editor erscheint
| Befehl | Im Editor | Wirkung |
|---|---|---|
git commit --status | Status als Kommentare | Zu committende Dateien sehen (Standard) |
git commit --no-status | Keine Dateiliste | Aufgeräumter Editor, weniger Ablenkung |
git commit -v | Vollständiger Diff | Beim Schreiben die genauen Änderungen prüfen |
git commit -q | Normaler Editor | Zusammenfassung nach dem Commit unterdrücken |
Besondere Commits
Commits in ungewöhnlichen Situationen erstellen
| Befehl | Erlaubt | Erzeugt Commit | Anwendungsfall |
|---|---|---|---|
--allow-empty | Keine Änderungen | ✓ | CI-Auslöser, Branch-Markierungen |
--allow-empty-message | Keine Nachricht | ✓ | Automatisierte Skripte (nicht empfohlen) |
--trailer "Key: value" | Metadaten | ✓ | Co-authored-by, Fixes, Reviewed-by |
Workflow-Beispiele
git add .Deine Änderungen stagen
git commit -m "Fix typo in README"Mit einer kurzen Nachricht committen
git add -AAlle Änderungen stagen
git commitÖffnet den Editor für eine mehrzeilige Nachricht
(Write: subject line, blank line, detailed body)Beim Formatieren die 50/72-Regel befolgen
git add forgotten-file.jsDie vergessene Datei stagen
git commit --amend --no-editZum letzten Commit hinzufügen, ohne die Nachricht zu ändern
git commit --amend -m "Corrected message"Letzten Commit mit neuer Nachricht ersetzen
git commit -a -m "Update config files"Geänderte/gelöschte verfolgte Dateien automatisch stagen und committen
git add .Änderungen stagen
git commit -S -m "Verified security patch"GPG-signierten Commit erstellen
Editor- und interaktive Tasten
Tastenkürzel, wenn Git einen Editor für deine Commit-Nachricht öffnet oder du interaktive Modi nutzt.
Vim (auf vielen Systemen Standard)
core.editor = vimNano
core.editor = nanoVS Code
core.editor = "code --wait"Patch-Modus (-p)
git commit -pFehlerbehebung
no changes added to commit (use "git add" and/or "git commit -a")
Ursache: Dateien wurden geändert, aber nichts ist gestagt – du hast 'git add' vergessen. (Siehst du 'nothing to commit, working tree clean', gibt es gar keine Änderungen.)
Stage Änderungen mit 'git add', bevor du committest. Mit 'git status' siehst du, was gestagt werden muss.
git add . && git commit -m "message"Please tell me who you are (Author identity unknown)
Ursache: Git verlangt, dass user.name und user.email vor deinem ersten Commit konfiguriert sind.
Konfiguriere deine Identität global oder für dieses Repository.
git config --global user.name "Your Name" && git config --global user.email "you@example.com"Aborting commit due to empty commit message
Ursache: Du hast den Editor ohne Nachricht geschlossen, oder die Nachricht enthielt nur Kommentare.
Schreibe im Editor eine Commit-Nachricht oder nutze die Option '-m' für eine Nachricht in der Zeile.
git commit -m "Your message here"pre-commit-Hook fehlgeschlagen
Ursache: Ein pre-commit-Hook (Linting, Tests, Formatierung) hat Probleme gefunden und den Commit blockiert.
Behebe die vom Hook gemeldeten Probleme. Umgehe ihn mit '--no-verify' nur, wenn es wirklich nicht anders geht.
git commit --no-verify -m "message"commit-msg-Hook fehlgeschlagen
Ursache: Deine Commit-Nachricht entspricht nicht dem Format, das die Projektkonventionen verlangen.
Halte dich an die Konvention für Commit-Nachrichten in deinem Projekt (z. B. das Format Conventional Commits).
git commit -m "feat: add new feature"Changes not staged for commit
Ursache: Du hast Dateien geändert, sie aber nicht zum Staging-Bereich hinzugefügt.
Nutze 'git add', um bestimmte Dateien zu stagen, oder 'git commit -a', um verfolgte Dateien automatisch zu stagen.
git add <file> && git commit -m "message"error: failed to push some refs (nach einem Amend)
Ursache: Du hast einen bereits gepushten Commit geamendet und damit eine abweichende Historie erzeugt.
Entweder Force-Push (wenn du allein auf dem Branch arbeitest) oder revert und einen neuen Commit erstellen.
git push --force-with-leaseYour branch is ahead of 'origin/main' by X commits
Ursache: Du hast lokale Commits, die noch nicht gepusht sind.
Das ist normal! Pushe, wenn du so weit bist, oder arbeite lokal weiter.
git push origin mainTipps & Stolperfallen
Best Practices
- ✓Schreibe klare Commit-Nachrichten: Beginne mit einem Verb (Add, Fix, Update, Remove) und halte den Betreff unter 50 Zeichen.
- ✓Nutze den Imperativ: Schreibe 'Add feature', nicht 'Added feature' – stell dir vor, du ergänzt „This commit will...“
- ✓Mache atomare Commits: Jeder Commit sollte genau eine logische Änderung enthalten. Mische keine Bugfixes mit neuen Features.
- ✓Vor dem Committen prüfen: Nutze 'git diff --staged', um genau zu sehen, was du gleich committest.
- ✓Gepushte Commits nie amenden: Amend schreibt die Historie um. Ändere nur Commits, die noch nicht geteilt wurden.
- ✓Betreff und Text durch eine Leerzeile trennen: Bei längeren Nachrichten ist die erste Zeile der Betreff, dann folgt eine Leerzeile, dann die Details.
- ✓Den Text bei 72 Zeichen umbrechen: So bleibt er in Terminals und in der Ausgabe von git log lesbar.
- ✓Issue-Nummern nennen: Füge 'Fixes #123' oder 'Closes #456' hinzu, um Commits mit dem Issue-Tracking zu verknüpfen.
- ✓Oft committen, seltener pushen: Kleine, häufige Commits sind leichter zu reviewen und rückgängig zu machen als große.
- ✓Keine generierten Dateien committen: Halte Build-Artefakte, Abhängigkeiten (node_modules) und kompilierte Dateien aus Commits heraus.
Häufige Fehler
- ✗'git commit' ausführen, ohne vorher zu stagen: Du musst zuerst 'git add' nutzen, außer bei 'git commit -a', das nur verfolgte Dateien stagt.
- ✗Vage Nachrichten wie 'fix' oder 'update' schreiben: Nutze klare, beschreibende Nachrichten, die erklären, WARUM die Änderung gemacht wurde.
- ✗Zu viele unabhängige Änderungen auf einmal committen: Mache atomare Commits – eine logische Änderung pro Commit erleichtert Review und Revert.
- ✗--amend auf Commits nutzen, die schon auf geteilte Branches gepusht sind: Amend schreibt die Historie um und macht anderen Probleme.
- ✗Vergessen, user.name und user.email zu konfigurieren: Git verlangt vor deinem ersten Commit eine Autor-Identität.
FAQ
'git commit' committet nur, was im Staging-Bereich liegt. 'git commit -a' stagt vor dem Commit automatisch alle geänderten und gelöschten verfolgten Dateien – aber NICHT neue unverfolgte Dateien. Für neue Dateien brauchst du weiterhin 'git add'.
Für nicht gepushte Commits: 'git reset --soft HEAD~1' behält die Änderungen gestagt, 'git reset HEAD~1' (wie --mixed) unstagt sie, 'git reset --hard HEAD~1' verwirft sie. Für gepushte Commits: Nutze 'git revert HEAD', um einen neuen Commit zu erzeugen, der die Änderungen rückgängig macht.
Für den letzten Commit: 'git commit --amend -m "New message"'. Für ältere Commits: Nutze 'git rebase -i' und ändere 'pick' in 'reword'. Mach das nie bei Commits, die schon auf geteilte Branches gepusht sind.
Git öffnet deinen konfigurierten Editor, damit du eine Nachricht schreibst. Schließt du ihn, ohne eine Nachricht zu speichern, wird der Commit abgebrochen. Nutze '-m' für eine Nachricht in der Zeile oder '--allow-empty-message', um ohne Nachricht zu committen (nicht empfohlen).
Stage die zusätzlichen Dateien mit 'git add <file>' und führe dann 'git commit --amend --no-edit' aus. So kommen sie in den vorigen Commit, ohne dessen Nachricht zu ändern.
'--amend' ersetzt den letzten Commit komplett (neuer Hash!). Nutze es, um Tippfehler in Nachrichten zu korrigieren oder vergessene Dateien hinzuzufügen. Nutze es nie bei Commits, die schon auf geteilte Branches gepusht sind – es schreibt die Historie um.
Nutze mehrere -m-Optionen: 'git commit -m "Subject" -m "Body paragraph"'. Jedes -m erzeugt einen neuen Absatz. Oder führe einfach 'git commit' aus, um den Editor zu öffnen.
Halte die Betreffzeile unter 50 Zeichen (harte Grenze 72). Brich den Text bei 72 Zeichen um. So bleibt alles im Terminal, in git log und in den Oberflächen von GitHub/GitLab lesbar.
Nutze 'git commit --no-verify' oder '-n'. Das umgeht die Hooks pre-commit und commit-msg. Sparsam einsetzen – Hooks sichern die Codequalität.
Ja, mit 'git commit --allow-empty -m "message"'. Nützlich, um CI/CD-Pipelines auszulösen oder Meilensteine in der Historie zu markieren, ohne Code zu ändern.