Commit-Hygiene
Überblick
Regel 4 von Jarretts Regeln: Eine Änderung hat nur die Commits, die sie logisch benötigt. Ein Reviewer liest einen sauberen Commit pro Änderung, nicht eine Historie von Versuchen. Kommentare sind kurz.
Der commit-check-Hook warnt, wenn eine git commit-Nachricht die Grenzen überschreitet. Er blockiert nicht. Du reparierst den Commit.
Wann verwenden
- Vor jedem Commit.
- Vor jedem Push.
- Wenn du mehr als einen Commit erstellt hast, um ein Problem zu beheben.
- Wenn der
commit-check-Hook warnt.
Ablauf
1. Die Nachricht schreiben
- Betreff: 72 Zeichen oder weniger. Verwende den Imperativ: "Add rules hook", nicht "Added rules hook".
- Body: 5 Zeilen oder weniger. Lass ihn weg, wenn der Betreff ausreicht.
- Sage, was sich geändert hat und warum. Beschreibe nicht jede Datei.
- Verwende vereinfachtes Englisch. Siehe die Skill
simplified-english.
2. Einen Commit pro logischer Änderung erstellen
- Eine logische Änderung: ein Feature-Ausschnitt, eine Fehlerbehebung oder ein Refactoring, das ein Reviewer als eine Einheit annehmen oder ablehnen kann.
- Mische kein Refactoring und eine Verhaltensänderung in einem Commit.
- Committe nicht jeden Versuch. Committe, wenn die Änderung funktioniert und die Tests bestanden werden.
3. Fix-Up-Commits vor dem Push squashen
Ein Fix-Up-Commit korrigiert einen früheren Commit in derselben Änderung. Beispiele: "fix typo", "wip", "address review".
- Erstelle den Fix-Up-Commit mit
git commit --fixup <sha>. - Squashe ihn ohne Editor:
GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash <base>. - Wenn der Rebase bei einem Konflikt stoppt, repariere die Dateien und führe
git add <dateien>aus. Führe dannGIT_EDITOR=true git rebase --continueaus. Um abzubrechen, führegit rebase --abortaus. - Führe die Tests erneut aus.
- Überprüfe das Ergebnis:
git log --oneline <base>..HEAD.
Wenn der letzte Commit der zu korrigierende ist, verwende git commit --amend --no-edit.
Warnung: Schreibe keine Commits um, die bereits auf einem gemeinsamen Branch sind. Frage zuerst den Benutzer. Ein Umschreiben zwingt jedes Teammitglied zum Zurücksetzen.
4. Kommentare kurz halten
- Schreibe einen Kommentar nur, wenn der Code nicht klar ist.
- Eine Zeile reicht normalerweise. Sage warum, nicht was.
- Schreibe keine Änderungshistorie in Kommentare. Git behält die Historie.
Häufige Rationalisierungen
| Rationalisierung | Realität |
|---|---|
| "Kleine Commits zeigen meinen Fortschritt." | Der Reviewer braucht das Ergebnis, nicht den Weg. Squashe die Versuche. |
| "Eine lange Nachricht gibt mehr Kontext." | Lange Nachrichten werden nicht gelesen. Den Kontext in die Spezifikation oder den PR setzen. |
| "Ich squashe später." | Später ist nach dem Push. Squashe vor dem Push. |
| "Der Hook warnt nur, also ist das Limit optional." | Das Limit ist eine Teamregel. Der Hook warnt, damit du es beheben kannst. |
Rote Flaggen
git logzeigt vor dem Push "wip", "fix", "oops" oder "try again".- Mehr als ein Commit für eine Fehlerbehebung.
- Ein Commit-Body, der jede geänderte Datei auflistet.
- Kommentare, die wiederholen, was der Code sagt.
Überprüfung
- Jeder Betreff ist 72 Zeichen oder weniger und verwendet den Imperativ.
- Jeder Body ist 5 Zeilen oder weniger.
-
git log --oneline <base>..HEADzeigt einen Commit pro logischer Änderung. - Vor dem Push sind keine Fix-Up-Commits übrig.
- Tests bestehen nach jedem Rebase.
Bekannte Einschränkung: Der Hook prüft git -C <verz> commit oder git -c <schlüssel>=<wert> commit nicht. Er überspringt auch einige Nachrichten, die er nicht lesen kann, z. B. -F <datei>.