Conventional Commits

Kurz: Eine Konvention für Commit-Nachrichten mit festem Format: <typ>(<scope>): <kurze Beschreibung>, z. B. feat(shop): ... oder fix(chat): ....

Genauer: Übliche Typen: feat (neues Feature), fix (Bugfix), refactor (Umbau ohne Verhaltensänderung), chore (Wartungsarbeiten wie Dependency-Updates), perf (Performance). Macht die Commit-History maschinenlesbar (z. B. für automatische Changelogs) und für Menschen auf einen Blick einordbar.

Kontext bei uns: Eigene Konvention für Emzett vereinbart — jeder Änderungs-”Batch” bekommt eine Commit-Message in diesem Format auf Deutsch, plus einen zusätzlichen “Warum”-Abschnitt mit der Begründung hinter der Entscheidung.

Im Detail

Vollständige Struktur

Die vollständige Spezifikation kennt neben dem einzeiligen Header noch einen optionalen Body (ausführlichere Erklärung, i. d. R. durch eine Leerzeile getrennt) und optionale “Footer” für strukturierte Zusatzinfos — z. B. BREAKING CHANGE: ... für Änderungen, die bestehende Nutzer der Codebasis betreffen, oder Closes #123, um einen Commit automatisch mit einem Issue zu verknüpfen. Ein ! direkt nach Typ/Scope (feat(api)!: ...) markiert ebenfalls einen Breaking Change, als Kurzform zum ausführlichen Footer.

feat(shop)!: Warenkorb-API auf neues Response-Format umgestellt

Alte Clients, die das bisherige Format erwarten, brechen mit diesem
Update - betrifft nur interne Konsumenten der API, keine externen.

BREAKING CHANGE: /api/cart gibt jetzt { items: [...] } statt ein
rohes Array zurück.
Closes #142

Automatisierung durch maschinenlesbare Struktur

Der eigentliche praktische Nutzen zeigt sich bei Tools, die diese Struktur automatisch auswerten: semantic-release oder ähnliche Tools können aus der Commit-History automatisch die nächste Versionsnummer nach Semantic Versioning ableiten — ein feat-Commit erhöht die Minor-Version, ein Commit mit BREAKING CHANGE die Major-Version, fix nur die Patch-Version — und daraus gleich einen lesbaren Changelog generieren, ganz ohne dass jemand manuell mitschreiben muss, was sich in welcher Version geändert hat. Das funktioniert allerdings nur zuverlässig, wenn WIRKLICH jeder Commit im Repository der Konvention folgt — schon ein einzelner Commit ohne korrektes Präfix kann die automatische Auswertung stören oder zu einer falsch berechneten Versionsnummer führen.

Weitere gebräuchliche Typen

Neben den Kern-Typen (feat, fix, refactor, chore, perf) haben sich in der Praxis weitere Konventionen etabliert, auch wenn sie nicht Teil der offiziellen Spezifikation sind: docs (reine Dokumentationsänderungen), test (Hinzufügen/Ändern von Tests ohne Produktionscode-Änderung), style (rein kosmetische Änderungen wie Formatierung, ohne Verhaltensänderung), und build/ci (Änderungen an Build-Konfiguration bzw. Continuous-Integration-Pipelines). Der Scope in Klammern ist optional, aber hilfreich, um auf einen Blick zu sehen, welcher Teil der Codebasis betroffen ist, ohne den ganzen Diff lesen zu müssen — bei größeren Projekten mit klar abgegrenzten Modulen (z. B. shop, chat, auth) macht das die Commit-History deutlich durchsuchbarer.

Grenzen der Konvention

Conventional Commits erzwingt Struktur, aber nicht Qualität — ein technisch korrekt formatierter Commit (fix(shop): Bug behoben) kann trotzdem inhaltlich nichtssagend sein, wenn die eigentliche Ursache oder Begründung fehlt. Deshalb ergänzen viele Teams die reine Typ/Scope-Struktur um die Pflicht, im Body kurz das “Warum” zu erklären (nicht nur das “Was”, das sich ohnehin aus dem Diff ablesen lässt) — Commit-Messages sind langfristig oft die einzige Stelle, an der die Motivation hinter einer Entscheidung dokumentiert bleibt.

Siehe auch: Next.js App Router, Git