Prüfen Sie eine Commit-Nachricht nach Conventional Commits und commitlint, mit ihrem Versionssprung
Läuft in Ihrem Browser. Nichts, was Sie eingeben, wird irgendwohin gesendet. Geprüft am 16. Oktober 2026.Ein Conventional Commit beginnt mit einem Typ, einem optionalen Scope und einer Beschreibung, etwa "fix(api): handle empty response". Fügen Sie eine Nachricht ein, um sie gegen die 12 Regeln von commitlints config-conventional zu prüfen, ihre Teile zu sehen und das Release, das sie bedeutet: feat ist minor, fix ist patch, ein Breaking Change ist major.
Diese Seite wurde maschinell aus dem englischen Original übersetzt. Die Übersetzung wurde noch von keinem Menschen geprüft; maßgeblich ist die englische Fassung. Englisches Original lesen
Fügen Sie die Commit-Nachricht ein oder tippen Sie auf einen Typ wie feat oder fix, um eine zu beginnen.
Lesen Sie das Ergebnis: jede verletzte Regel in einfachen Worten, mit den Teilen, als die die Nachricht gelesen wurde.
Korrigieren Sie die Nachricht, bis sie besteht; die Release-Zeile zeigt, ob sie eine Major-, Minor- oder Patch-Version bedeutet.
Für einen ganzen Pull Request wechseln Sie zu Eine Liste von Headern und fügen die Ausgabe von git log --format=%s ein.
Conventional Commits ist ein kleines Format für Commit-Nachrichten, das Werkzeuge lesen können: Release-Werkzeuge bestimmen daraus die nächste Versionsnummer, und Changelog-Werkzeuge machen daraus Release Notes. Viele Teams erzwingen es mit commitlint in einem commit-msg-Hook, und eine abgelehnte Commit-Nachricht ist ein häufiges kleines Ärgernis.
Das Format. Ein Header, dann optional ein Body und Footer, jeweils durch eine Leerzeile getrennt:
| Teil | Beispiel | Regel |
|---|---|---|
| Typ | feat, fix, docs |
Einer von 11, kleingeschrieben |
| Scope | (api) |
Optional, in Klammern |
| Breaking | ! vor dem Doppelpunkt |
Oder ein BREAKING CHANGE-Footer |
| Beschreibung | add login page |
Kleiner Anfangsbuchstabe, kein Punkt |
| Header-Länge | Höchstens 100 Zeichen | |
| Footer | Closes #123 |
Nach einer Leerzeile |
Was geprüft wird. Die zwölf Regeln von @commitlint/config-conventional: zehn Fehler (Typ leer, Typ-Schreibweise, Typ-Liste, Beschreibung leer, Beschreibungs-Schreibweise, Schlusspunkt, Header-Länge, Leerzeichen im Header, Zeilenlänge von Body und Footer) und zwei Warnungen (eine Leerzeile vor dem Body und vor dem Footer). Jeder Fehler wird in einfachen Worten mit der Korrektur erklärt.
Der Versionssprung. Die Spezifikation ordnet Commits der semantischen Versionierung (Semantic Versioning) zu: fix bedeutet ein Patch-Release, feat ein Minor-Release und jeder Breaking Change, markiert mit ! oder einem BREAKING CHANGE-Footer, ein Major-Release. Andere Typen wie docs oder chore ändern die Version für sich allein nicht.
Ein ganzer Pull Request. Wechseln Sie in den Listenmodus und fügen Sie die Ausgabe von git log --format=%s main..HEAD ein, ein Header pro Zeile. Jeder Header besteht oder scheitert, und das Release, das sich insgesamt ergibt, wird genannt.
Die Ergebnisse wurden mit @commitlint/lint 19 und config-conventional an mehr als 100 Nachrichten überprüft. Alles läuft in Ihrem Browser; nichts, was Sie eingeben, wird irgendwohin gesendet.
Eine Commit-Nachricht, deren erste Zeile aus einem Typ, einem optionalen Scope in Klammern, einem Doppelpunkt, einem Leerzeichen und einer kurzen Beschreibung besteht, etwa fix(api): handle empty response. Das Format stammt aus der Spezifikation Conventional Commits 1.0.0, und Werkzeuge nutzen es, um automatisch die nächste Versionsnummer zu bestimmen und Changelogs zu schreiben.
Verwenden Sie feat für eine Änderung, die Nutzer als neue Funktion sehen, fix für eine Fehlerbehebung und chore für Wartung, die keins von beiden ändert, etwa Aktualisierungen von Abhängigkeiten. Releases ergeben sich daraus: feat erzeugt eine Minor-Version, fix einen Patch und chore für sich allein kein Release. docs, style, refactor, perf, test, build und ci sind die anderen Standardtypen.
Setzen Sie ein Ausrufezeichen vor den Doppelpunkt, wie in feat(api)!: remove the v1 endpoints, oder fügen Sie nach einer Leerzeile einen Footer hinzu, der mit BREAKING CHANGE: beginnt und sagt, was bricht. Beides macht das Release zu einer Major-Version, unabhängig vom Typ. Beides zusammen ist erlaubt und üblich.
Meist, weil der Header nicht genau dem Muster type: description entspricht, sodass commitlint weder einen Typ noch eine Beschreibung findet. Häufige Ursachen sind ein fehlendes Leerzeichen nach dem Doppelpunkt, ein Leerzeichen davor, ein großgeschriebener oder unbekannter Typ oder gar kein Typ. Fügen Sie die Nachricht hier ein, um zu sehen, welcher Teil falsch gelesen wurde.
Nicht mit config-conventional: Die Regel subject-case lehnt Beschreibungen in sentence case, start case, pascal case oder upper case ab, daher scheitert Add login und add login besteht. Text in Backticks oder Anführungszeichen wird bei dieser Regel ignoriert, ein Name wie `Button` am Anfang ist also in Ordnung. Teams, die Großbuchstaben wollen, ändern die Regel in ihrer eigenen Konfiguration.
Nein. Standardmäßig überspringt commitlint Merge-Commits, von git geschriebene Reverts, fixup!- und squash!-Commits sowie Header, die nur aus einer Versionsnummer bestehen, etwa 1.2.3 oder chore(release): 1.2.3. Diese Seite überspringt dieselben Nachrichten und sagt das, sodass eine Prüfung hier dasselbe Ergebnis liefert wie der Hook.
Sätze und Regeln ändern sich; prüfen Sie die Quelle, bevor Sie sich auf eine Zahl verlassen.
Kommen Sie nicht weiter? Fragen Sie zu Conventional-Commits-Prüfer und jeder, der es weiß, kann antworten. Kein Konto nötig.