Git & Version Control
Felder zusammensetzen oder eine vollständige Nachricht prüfen. Beide Entwürfe bleiben beim Wechsel erhalten.
Die Vorschläge sind übliche Typen. Eigene Typen sind möglich.
Mit Refs: #42 oder Closes #42 beginnen. Normale Folgezeilen setzen den vorherigen Wert fort.
Nachrichten bleiben in diesem Browser. Kein Repository-Zugriff und keine Datenübertragung.
Struktur nach Conventional Commits 1.0.0; keine Projektregeln oder Grenze von 50/72 Zeichen. Maximal 20.000 UTF-16-Einheiten.
Beschreibung oder vollständige Nachricht eingeben.
Der Commit-Nachrichten-Generator hilft beim letzten Blick auf eine Nachricht: Steht die Beschreibung wirklich in der ersten Zeile, beginnt der Text nach einer Leerzeile, und ist eine inkompatible Änderung ausdrücklich markiert? Konventionelle Commits geben diesen Bestandteilen eine Bedeutung. Hier bleiben Formular und Prüftext als getrennte Entwürfe erhalten, während die Ausgabe genau die daraus entstehende Nachricht zeigt.
Der Commit-Nachrichten-Generator setzt Typ, optionalen Gültigkeitsbereich und Beschreibung zu einer Kopfzeile zusammen. Zwischen Text und Footer fügt er die erforderlichen Leerzeilen ein. Innere Absätze bleiben erhalten. So lässt sich der Aufbau beurteilen, ohne dass eigene Typen oder die Schreibweise automatisch ersetzt werden.
feat erklärt üblicherweise eine Minor-Änderung. Ein ! vor dem Doppelpunkt oder ein gültiger Breaking Change im Footer erklärt dagegen Major, unabhängig vom Typ. Die Übersicht macht diese Priorität sichtbar. Sie untersucht keinen Quellcode und entscheidet deshalb nicht, ob tatsächlich eine Schnittstelle inkompatibel geworden ist.
Die Liste enthält gebräuchliche Typen, ist aber keine Vorgabe. Eigene Bezeichnungen lassen sich direkt eingeben. Wähle den Typ nach der tatsächlichen Änderung; die Nachricht allein reicht nicht, um einen Bugfix von einer Erweiterung zuverlässig zu unterscheiden.
Beginne etwa mit Refs: #42 oder Closes #42. Eine normale Folgezeile gehört zum vorherigen Wert; erst ein weiteres gültiges Token beginnt einen neuen Footer. Das Formular ergänzt die Abschnittslücken, während du Inhalt und Zuordnung kontrollierst.
Automatische Verarbeitung startet nach 350 ms Ruhe. Ausgeschaltet erscheinen die Aktion und die Tastenkombination Strg/Cmd + Enter. Jede Änderung an Text, Feldern oder ! sperrt sofort Kopie und Download, bis genau diese Eingabe erneut verarbeitet wurde.
Typ, Scope und einzeilige Beschreibung bilden den Kopf. Danach sind mehrere Absätze und Footer möglich. Die Schreibweise bleibt erhalten; FEAT und feat haben dieselbe erklärte Wirkung. Beschreibung und Werte dürfen deutsch sein. Die Kopflänge wird gezählt, aber 50 oder 72 Zeichen sind hier keine Fehlergrenze.
Im Prüfmodus werden Kopfsyntax, notwendige Leerzeile und erkennbare Footer geprüft. Fehler zeigen Quellzeile und Spalte; der Editor markiert die Zeile. Ein Doppelpunkt in einem gewöhnlichen Satz macht den Text nicht ungültig. Der Formularentwurf bleibt auch nach dem Wechsel unverändert verfügbar.
Ein ! gehört nach Typ beziehungsweise Scope und direkt vor den Doppelpunkt. Damit ist ein zusätzlicher Footer optional. Alternativ sind BREAKING CHANGE: Beschreibung und BREAKING-CHANGE: Beschreibung zulässig. Diese besonderen Tokens müssen großgeschrieben sein. Werte dürfen sich über mehrere Zeilen erstrecken.
Beides ist erlaubt. Die Spezifikation verlangt eine Auswertung ohne Unterscheidung der Groß- und Kleinschreibung. Das Werkzeug erhält den eingegebenen Typ und erkennt auch FEAT. Die besonderen Footer-Tokens BREAKING CHANGE und BREAKING-CHANGE müssen jedoch großgeschrieben werden.
Möglichst verschiedene Änderungen in getrennte Commits aufteilen. Eine Nachricht hat hier genau ein Typfeld. Der Text kann Zusammenhänge erläutern, doch ein ausgewähltes feat bestätigt nicht, dass alle enthaltenen Änderungen passend eingeordnet wurden. Prüfe eine mögliche Inkompatibilität unabhängig davon.
fix erklärt Patch, feat Minor und ein ! oder gültiger Breaking-Footer Major. Die inkompatible Änderung hat Vorrang vor dem Typ. Hier wird nur diese Erklärung gezeigt. Aktuelle Version, Vorabversionen und Regeln deiner Release-Pipeline werden nicht berücksichtigt.
Bei einem Entwurf den Typ korrigieren und erneut prüfen. Ein Tippfehler wie feet kann formal gültig sein, weil eigene Typen erlaubt sind. Bereits angelegte Commits zu ändern ist eine gesonderte Repository-Aufgabe; dieses Werkzeug führt weder amend noch rebase aus.
Die Spezifikation überlässt Revert-Verhalten den jeweiligen Werkzeugen. Ein revert-Typ mit Refs-Footer kann die betroffenen Commits benennen. Die Prüfung akzeptiert diese Struktur, verrechnet aber keine früheren Änderungen und bestimmt keine daraus folgende Release-Version.
Fehlt ein Nachrichtenformat?
Den Commit-Nachrichten-Generator erneut öffnen, die erklärte Wirkung mit dem tatsächlichen Diff vergleichen und erst das aktuelle, geprüfte Ergebnis übernehmen.