Gute Commit-Nachrichten: das Warum festhalten

Ziel

Die Historie soll die Frage beantworten, die eine spätere Leserin stellen wird: Warum wurde das geändert, und was sollte es bewirken?

Voraussetzungen

Eine logische Änderung pro Commit. Vermischt ein Diff eine Umstrukturierung mit einer Verhaltensänderung, zuerst trennen.

Schritte

1. Betreffzeile von etwa 50 Zeichen im Imperativ («Veraltete If-Match-Token abweisen»), wie in Pro Git empfohlen; sie erscheint in Logs, Blame-Ansichten und Review-Werkzeugen.
2. Leerzeile, dann die Motivation: welches Problem bestand, welche Alternativen erwogen wurden, was die Änderung bewusst nicht tut.
3. Beobachtbare Folgen nennen: neues Verhalten, Migrationsschritte, geänderte Standardwerte. Auf Tickets per Kennung verweisen, nicht per Kopie.
4. Den Diff nicht zeilenweise beschreiben; beschreiben, was der Diff nicht zeigen kann.
5. Die Nachricht nach einer Pause erneut lesen. Steht dort nur «Fix» oder «Update», fällt sie durch.

Erwartetes Ergebnis

Wer nur die Nachricht sieht, kann Absicht und Abwägung wiedergeben. git log --oneline liest sich als Liste von Entscheidungen, nicht von berührten Dateien.

Grenzen und Prüfbasis

Formregeln wie die Zeilenlänge sind Konventionen aus der zitierten Anleitung, keine Anforderungen von Git. Automatische Prüfungen erkennen die Form, nicht den Sinn.