Commits, die eine Geschichte erzählen

Eine Commit-Nachricht ist die einzige Dokumentation, die für immer mit dem Code reist. Kommentare werden gelöscht, Wikis veralten, Tickets werden archiviert – aber git log ist dauerhaft. Teams, die gute Commits schreiben, können in ihrer eigenen Historie navigieren. Teams, die das nicht tun, betreiben innerhalb von sechs Monaten Archäologie in ihrer eigenen Codebasis.

Ein guter Commit hat eine klare Betreffzeile im Imperativ („Add rate limiting to auth endpoint", nicht „Added rate limiting" oder „rate limiting stuff"), einen optionalen Body, der erklärt, warum die Änderung vorgenommen wurde (nicht was – der Diff zeigt was), und enthält genau eine logische Änderung.

fix: prevent duplicate webhook deliveries

The webhook dispatcher was firing on both the DynamoDB stream event
and the API Gateway trigger. Deduplicate by checking idempotency key
before dispatch.

Vergleichen Sie das mit dem, was die meisten Repositories tatsächlich enthalten:

fix stuff
wip
updates

Der erste Commit ist durchsuchbar, revertierbar und selbstdokumentierend. Die zweite Gruppe ist Rauschen. In sechs Monaten sagt Ihnen „fix stuff" nichts – Sie müssen den Diff lesen, den Kontext rekonstruieren und die Absicht erraten. Die 10 Sekunden, die Sie mit einer faulen Nachricht gespart haben, kosten 10 Minuten jedes Mal, wenn jemand darauf stößt.

Conventional Commits fügen jeder Commit-Betreffzeile ein leichtgewichtiges Präfix hinzu, das Ihre Historie maschinenlesbar macht, ohne die menschliche Lesbarkeit zu opfern. Das Format ist einfach:

feat: add dark mode toggle to settings
fix: correct timezone offset in standup scheduler
chore: upgrade TypeScript to 5.7
docs: add API rate-limit documentation
refactor: extract validation logic from route handler

Das Präfix zeigt Ihnen auf einen Blick die Kategorie der Änderung. feat bedeutet neues benutzersichtbares Verhalten. fix bedeutet, dass ein Fehler korrigiert wurde. chore bedeutet Wartung, die Benutzer nicht betrifft. Das kostet nichts – Sie schreiben bereits eine Betreffzeile, Sie stellen nur 4–8 Zeichen voran.

Der Gewinn sind automatische Changelogs, semantische Versionierung (ein feat erhöht die Minor-Version, ein fix erhöht den Patch), und sofortiges Filtern (git log --grep="^fix:" zeigt Ihnen jeden Bugfix im letzten Quartal). Teams, die Conventional Commits übernehmen, berichten, dass ihre PRs schneller reviewt werden, weil der Reviewer weiß, welche Art von Änderung zu erwarten ist, bevor er eine einzige Zeile Diff liest.

Sie brauchen keine Tools, um anzufangen. Einigen Sie sich einfach als Team auf die Präfixe und setzen Sie sie im Code-Review durch. Fügen Sie später Automatisierung hinzu, wenn Sie möchten – aber die Konvention ist an sich nützlich.

Ein Commit sollte genau eine logische Änderung darstellen. Nicht „alles, was ich heute gemacht habe", nicht „alle Dateien, die ich für dieses Feature angefasst habe", und definitiv nicht „WIP" – eine Nachricht, die nichts kommuniziert und den Commit ohne Nebenwirkungen unrevertierbar macht.

Atomare Commits sind aus zwei praktischen Gründen wichtig. Erstens, Revertierbarkeit: Wenn ein Commit eine Sache macht, macht das Revertieren eine Sache rückgängig. Wenn ein Commit drei Sachen macht und eine davon kaputt ist, macht das Revertieren alle drei rückgängig – einschließlich der zwei, die in Ordnung waren. Sie beheben jetzt Kollateralschäden Ihres eigenen Rollbacks.

Zweitens, Bisectierbarkeit: git bisect durchsucht Ihre Commit-Historie binär, um zu finden, welcher Commit einen Fehler eingeführt hat. Es ist eines der mächtigsten Debugging-Tools von Git – aber es funktioniert nur, wenn jeder Commit eine kohärente Einheit ist. Wenn Ihre Commits unzusammenhängende Änderungen mischen, zeigt Ihnen bisect auf einen Commit, der sowohl die schuldige Änderung als auch drei unschuldige enthält, und Sie sind wieder beim manuellen Lesen von Diffs.

Der „WIP"-Commit ist der Feind beider Eigenschaften. Er sagt „Ich war noch nicht fertig mit Denken" – was bedeutet, dass der Commit teilweise abgeschlossene Arbeit enthält, die nicht sauber revertiert, nicht sinnvoll bisectiert und nicht isoliert verstanden werden kann. Wenn Sie laufende Arbeit speichern müssen, verwenden Sie git stash oder einen Draft-Branch. Verschmutzen Sie nicht die gemeinsame Historie mit Checkpoints, die keinen semantischen Wert haben.