Zum Inhalt springen
100% lokal

Conventional Commit Builder

Stellen Sie eine Conventional Commits-Nachricht aus Typ, Bereich und Beschreibung zusammen oder prüfen Sie vorhandene Nachrichten auf Probleme.

Eingabe
Ausgabe

Conventional Commit Builder

Conventional Commits ist das Format "type(scope): description", das Changelog-Generatoren, semantic-release und commitlint erwarten. Dieses Tool stellt sie für Sie zusammen: Wählen Sie einen Typ aus, fügen Sie einen optionalen Bereich hinzu, schreiben Sie die Beschreibung, und es erstellt den Header — plus einen Body und eine Fußzeile mit Ticketreferenzen, wenn Sie diese hinzufügen. Wechseln Sie zum Prüfmodus, um das Gegenteil zu tun: Fügen Sie eine oder mehrere vorhandene Commit-Nachrichten, eine pro Zeile, ein und sehen Sie genau, was an jeder falsch ist.

Die Typliste umfasst die standardisierte Menge — feat, fix, docs, style, refactor, perf, test, build, ci, chore und revert. Ein Breaking-Change-Schalter markiert den Header mit "!" und fügt nach dem Hinweis eine "BREAKING CHANGE:"-Fußzeilenlinie an, genau wie die Spezifikation erwartet. Die Max-Header-Länge-Option setzt das Längenlimit durch, auf das sich Ihr Team geeinigt hat (der Standard von commitlint ist 72 Zeichen); das Erzwingen eines Kleinbuchstabens am Anfang und das Verbieten eines abschließenden Punkts sind die zwei Stilregeln, die die meisten Commit-Linter standardmäßig überprüfen, und beide können deaktiviert werden, wenn Ihr Team diese nicht verwendet.

Im Prüfmodus wird jede Zeile als ein vollständiger Commit-Header behandelt, daher werden bei der Eingabe von "git log --oneline" mehrere auf einmal überprüft. Wählen Sie, ob die Ausgabe ein Bericht ist — die ursprüngliche Zeile gefolgt von den Fehlern — oder die korrigierte Nachricht, automatisch in Kleinbuchstaben und entscharft, wo dies eindeutig ist. Eine Zeile, die nicht der Form "type(scope): description" folgt, wird unberührt gelassen, anstatt erraten zu werden.

Alles läuft in Ihrem Browser, daher verlassen Commit-Nachrichten aus einem privaten Repository niemals Ihren Computer. Kopieren Sie das Ergebnis, laden Sie es als .txt-Datei herunter oder geben Sie es zur weiteren Verfeinerung zurück in die Eingabe ein.

Häufige Fragen

Was ist ein Conventional Commit?
Eine Commit-Nachricht geschrieben als "type(scope): description", optional gefolgt von einem Body und einer Fußzeile. Tools wie commitlint, semantic-release und Changelog-Generatoren analysieren dieses Format, um Versionsbumps zu entscheiden und Versionshinweise zu gruppieren.
Wie funktioniert der Prüfmodus?
Fügen Sie eine Commit-Nachricht pro Zeile ein — nur einen Header, wie eine Zeile aus "git log --oneline". Jede Zeile wird anhand der Typliste, des Header-Längenlimits und Ihrer Klein-/Periodenbregeln validiert und separat gemeldet.
Wie markiere ich eine Breaking Change?
Aktivieren Sie "Breaking Change" und fügen Sie einen Hinweis hinzu. Der Header erhält vor dem Doppelpunkt ein "!" und nach der Notiz eine "BREAKING CHANGE: ..."-Fußzeilenlinie, die der Spezifikation von Conventional Commits entspricht.
Kann ich Ticketreferenzen zur Fußzeile hinzufügen?
Ja — geben Sie sie in das Fußzeilenfeld ein, z. B. "Schließt #123, verweist auf JIRA-456". Sie wird als eigene Zeile nach dem Body hinzugefügt.
Wird mein Commit-Verlauf irgendwo hochgeladen?
Nein. Das Erstellen und Überprüfen von Commit-Nachrichten läuft vollständig in Ihrem Browser — nichts, was Sie eingeben oder einfügen, wird an einen Server gesendet.