Eine Conventional-Commit-Message bauen
Conventional Commits ist ein Format für git-Messages, das Chaos ("update", "fix stuff", "wip") in eine lesbare Historie verwandelt. Jeder Commit startet mit einem Type (`feat`, `fix`, `docs`, `refactor`...), optional einem Scope in Klammern (z. B. `feat(auth):`), dann einer kurzen Description. Lesbar für Menschen, parsbar für Maschinen.
Dieses Tool setzt eine Commit-Message aus einem Formular zusammen. Type aus der Bar wählen (11 Types), kurze Description tippen, optional Scope, Body, Breaking Change (ergänzt `!` nach dem Type und einen `BREAKING CHANGE:`-Footer), Footers (Closes #123, Co-authored-by, Signed-off-by).
Du kriegst das Ergebnis in drei Formaten: Plain Text (in den Editor nach `git commit` pasten), Shell-Befehl (`git commit -m "..."` mit escapten Quotes), JSON (für Bots wie semantic-release).
Live-Validierung: kurze Description max 72 Zeichen (Hard-Limit), kein Punkt am Ende, Präsens ("add", nicht "added").
So nutzt du das Tool
- Commit-Type oben wählen. feat (neues Feature), fix (Bugfix), docs (Doku), refactor (Code-Änderung ohne Verhaltensänderung), perf (Performance), test, build, ci, chore (kleines Cleanup), revert, style (Formatierung).
- Scope (optional), welcher Teil des Codebases der Commit anfasst, z. B. `auth`, `api`, `ui`. Preset-Chip klicken oder eigenen tippen. Erscheint in Klammern: `feat(auth): ...`.
- Kurz-Description, eine Zeile, max 72 Zeichen, kein Punkt am Ende, Präsens ("add login flow", nicht "added login flow"). Der Counter zeigt die Länge, warnt bei Überlänge und wenn er Vergangenheit erkennt.
- Breaking Change (Switch), anschalten, wenn der Commit Rückwärts-Kompatibilität bricht (API-Änderung, Feature entfernt, Semantik-Änderung). Der Generator ergänzt `!` nach dem Type (`feat!:`) und einen `BREAKING CHANGE: description`-Footer.
- Body (optional), die Details. Schreib warum hier (Kontext, Motivation), nicht was (das zeigt das Diff).
- Footers (optional), Zeilen mit Buttons: Closes #123 (schließt ein Issue), Refs #456 (verwandtes Issue, schließt nicht), Co-authored-by (zweiter Autor, z. B. nach Pair-Programming), Signed-off-by (DCO, Developer Certificate of Origin, von Projekten wie Linux-Kernel verlangt), Reviewed-by, Custom (eigener Key).
- Output-Format wählen (Plain / Shell / JSON) und kopieren. Plain in den git-Editor nach `git commit`. Shell direkt ins Terminal. JSON füttert einen CI-Bot oder Changelog-Generator.
Wann das nützlich ist
Konkrete Situationen, in denen Conventional Commits die Qualität eines Projekts verändern:
- Automatische Releases. semantic-release oder release-please analysieren Commits seit dem letzten Release. feat -> Minor bumpen (1.4.0 -> 1.5.0). fix -> Patch bumpen (1.4.0 -> 1.4.1). BREAKING CHANGE -> Major bumpen (1.4.0 -> 2.0.0). Null Handarbeit.
- Automatisches CHANGELOG.md. Nach einem Release generiert das Tool eine "What's new in 1.5.0"-Section, gruppiert in "Features", "Bug Fixes", "Performance Improvements". Jede Zeile verlinkt zum Commit. Geht auch von Hand mit unserem Changelog-Generator.
- Lesbare git-History. `git log --oneline` zeigt "feat(auth): add magic link login", "fix(api): handle empty body", "docs: clarify install steps". Nicht "update", "fix", "wip". Jeder neue Teamkollege versteht die History auf einen Blick.
- Schnellerer Code-Review. Der Reviewer sieht das Präfix und weiß, ob es ein feat ist (genau auf Tests und Edge-Cases schauen) oder ein refactor (genau schauen, das Verhalten sollte sich nicht geändert haben). Sie können PRs nach Type filtern.
- PR-Templates und CI-Checks. Viele Projekte (Vercel, Astro, Next.js) haben CI-Validierung, dass der PR-Titel ein Conventional Commit ist. Hier einen validen Titel generieren, damit der Bot dich nicht zurückschickt.
- Arbeit im Monorepo. Der Scope im Commit (`feat(web):`, `fix(api):`) sagt dir, in welchem Paket/App die Änderung ist. Changelogs gruppieren sie separat.
Nach einer Reihe Commits den CHANGELOG-Generator nutzen, der Commits nach Type gruppiert. Und baust du eine Projekt-README, ist die "Contributing"-Section ein guter Platz, Conventional Commits zu erwähnen, der README-Builder hat ein fertiges Template.