Conventional-Commit-Nachrichten prüfen und zerlegen

Er erkennt die gängigen Typen für Build, Wartung, CI, Dokumentation, Funktionen, Fehlerkorrekturen, Leistung, Refactoring, Rücknahmen, Stil und Tests. Damit finden Sie fehlerhafte Header oder unbekannte Typen, bevor sie in den gemeinsamen Verlauf, einen Veröffentlichungsablauf oder ein automatisches Änderungsprotokoll gelangen. Das kompakte Ergebnis lässt sich ohne zusätzliche Textanalyse direkt in Skripten verwenden.

Prüfen Sie den Header und lesen Sie wichtige Felder aus

Senden Sie die vollständige Commit-Nachricht im Textfeld. Der Prüfer vereinheitlicht Zeilenenden und untersucht die erste Zeile als Conventional-Commits-Header. Darunter darf die Nachricht weiterhin eine Leerzeile, Textabsätze und Fußzeilen enthalten. Ein gültiger Header beginnt mit einem erkannten Typ in Kleinbuchstaben. Danach kann ein Bereich in Klammern folgen. Ein Ausrufezeichen darf einen Kompatibilitätsbruch kennzeichnen. Anschließend müssen ein Doppelpunkt, genau ein trennendes Leerzeichen und eine nicht leere Beschreibung stehen. Beispielsweise liefert <code>feat(parser): support escaped delimiters</code> den Typ <code>feat</code>, den Bereich <code>parser</code> und die Beschreibung <code>support escaped delimiters</code>. Das normale Ergebnis enthält außerdem <code>valid: true</code> und ein boolesches Feld für den Bruchstatus. Fehlt der Bereich, wird die Eigenschaft ausgelassen, statt einen irreführenden leeren oder null-Wert zu erhalten. Syntaxfehler und unbekannte Typen erzeugen einen Fehler für ungültige Eingaben mit einer klaren Erläuterung. Dadurch kann ein Editor-Hook oder eine Pipeline eine hilfreiche Korrektur anzeigen, ohne ein nur teilweise analysiertes Ergebnis deuten zu müssen.

Verstehen Sie die erkannte Konvention

Conventional Commits legt die Form eines Headers fest, lässt Projekten aber Raum für ein eigenes Typvokabular. Diese Fähigkeit verwendet bewusst eine feste, praktische Auswahl, damit Ergebnisse repositoryübergreifend vorhersehbar bleiben: build, chore, ci, docs, feat, fix, perf, refactor, revert, style und test. Ein formal richtig aufgebauter Header mit einem anderen Wort schlägt trotzdem fehl, denn die Annahme beliebiger Wörter würde die gewünschte Typprüfung wirkungslos machen. Typen müssen kleingeschrieben sein. Bereiche sind optional und dürfen Kleinbuchstaben, Ziffern, Punkte, Unterstriche, Schrägstriche oder Bindestriche enthalten; sie müssen mit einem Buchstaben oder einer Ziffer beginnen. Dadurch sind übliche Bereiche wie <code>api</code>, <code>web-client</code> und <code>packages/core</code> möglich, während mehrdeutige Leerzeichen und nicht geschlossene Klammern abgelehnt werden. Die Beschreibung behält ihre ursprüngliche Zeichensetzung und Großschreibung, darf jedoch nicht mit Leerraum beginnen oder enden. Ein Ausrufezeichen direkt vor dem Doppelpunkt kennzeichnet einen Kompatibilitätsbruch und wird gesondert zurückgegeben. Eine Fußzeile mit <code>BREAKING CHANGE</code> darf im Text verbleiben; der aktuelle boolesche Wert wird jedoch ausschließlich aus dem Headerzeichen abgeleitet und wertet Fußzeilen nicht semantisch aus.

Binden Sie die deterministische Prüfung in Abläufe ein

Nutzen Sie den Prüfer möglichst früh, sobald eine vorgeschlagene Nachricht vorliegt: in einem Commit-Editor-Hook, einer Pull-Request-Prüfung, einer Merge-Warteschlange oder einem Dienst zur Vorbereitung von Veröffentlichungsmetadaten. Ein lokaler Hook liefert die schnellste Rückmeldung. Eine serverseitige Prüfung stellt zusätzlich sicher, dass durch Automatisierung oder alternative Clients erzeugte Commits dieselbe Richtlinie einhalten. Der Parser arbeitet deterministisch und durchsucht die Zeichenfolge innerhalb fester Grenzen. Er kontaktiert keinen Repository-Anbieter, untersucht kein Git-Objekt, leitet keine Absicht aus einem Diff ab, verändert die Beschreibung nicht und nutzt keinen externen Dienst. Dieselbe Eingabe erzeugt daher im Browser und über die API dieselben Felder oder denselben Fehler. Verwenden Sie Typ, Bereich und Beschreibung als Klassifikationsdaten für Änderungsprotokolle, Veröffentlichungsregeln oder Übersichten, halten Sie projektspezifische Semantikprüfungen jedoch getrennt. Der Prüfer kann etwa bestätigen, dass <code>fix(auth): reject expired tokens</code> strukturell gültig ist. Er kann weder beweisen, dass die Änderung einen Fehler behebt, noch dass <code>auth</code> ein zulässiges Paket ist. Ergänzen Sie deshalb bei Bedarf Repository-Regeln für strengere Bereichslisten oder Ticketverweise.