Was sind Conventional Commits?
Conventional Commits ist eine einfache Konvention, welche das Format der Commit-Nachrichten beschreibt. Die Struktur ist sehr ähnlich zu der allgemeinen Empfehlung. Auf die Conventional Commits Seite findest du die Dokumentation dafür.
Die Struktur wird in drei Bereiche unterteilt. Nennen wir sie einfach: Betreffzeile, Beschreibung und Fußnoten. Der Erste ist Pflicht und die andere zwei sind optional, obwohl ich euch empfehle zumindest die Beschreibung zu Nutzen, um die Aussagekraft der Commit-Nachricht zu erhöhen.
Betreffzeile
Sie fängt mit der Angabe des Änderungstyps an. Es gibt zwei fest definierte Typen: „feat“, abgeleitet von Feature für neue Funktionalität und „fix“ für Fehlerkorrekturen. Warum die zwei? Das hängt mit „semver“ und die automatische Vergabe von Versionsnummern zusammen. Das bedeutet aber nicht, dass du darauf beschränkt bist. Es gibt einige Andere, die allgemein genutzt werden. Auf die oben genannte Conventional Commits Seite werden weitere genannt. Ich rate dir, sie auch zu nutzen und Neue zu erfinden, wenn du sie braucht.
Wir sind noch in der Betreffzeile. Als Nächstes kommt der Bereich, immer in runden Klammern. Hier hast du freie Wahl. Gibt an, was für dich Sinn ergibt. Wenn du in einem Team arbeitest, dann ist meistens eine gute Idee, die möglichen Bereiche miteinander zu definieren. Was sollten eigentlich die Bereiche beschreiben? Nutze Wörter, um klar zu machen, welches Teil der Anwendung betroffen ist. Da gibt es keine feste regeln. Entscheide selbst was für Dich und deinem Team sinnvoll ist.
Der dritte und letzte Teil der Betreffzeile ist die Bezeichnung. Hier gibst du kurz und prägnant an, um was es geht. Sie wird von Typ und Bereich durch einen Doppelpunkt und ein Leerzeichen getrennt.
Die Beschreibung
Sie ist ein beliebig langer Text. Hier kommt alles zum Tragen, was ich in mein früheren Mini-Blog erzählt habe. Denk daran, was geändert wird, warum es nötig ist, wie findet die Änderung statt, usw.
Die Fußzeilen
Jeder Art von Zusatzinformation kann jetzt angegeben werden. Es muss nur ein bestimmtes Format haben. Na ja, eigentlich gibt es zwei Möglichkeiten. Aber eins nach dem anderen. Jede Fußzeile nimmt eine Zeile platz ein (was für eine Überraschung). Du kannst die Informationen als Key-Value-Pair eingeben. Zum Beispiel „Reviewer: Alex“. Du kannst so viele Fußzeilen verwenden, wie du möchtest. Gehe sparsam damit um. Denke daran: „ so wenig wie möglich, so viel wie nötig“.
Es gibt eine zweite Variante, um die Fußzeile zu formatieren. Diese nutzt du zum Beispiel, um dein Ticket zu verlinken. Das machst du so: „Close #1234“.
Breaking Changes
Ein Extra gibt es noch dazu. Wenn deine Anpassung dazu führt, dass die öffentliche Schnittstelle deine Anwendung sich ändert, auch „Breaking Change“ genannt, dann willst du das auch in deine Commit-Nachricht deutlich machen. Warum denn das? Na ja, einerseits soll, jeder dem es interessiert darüber informiert werden. Das gehört wohl dazu. Andererseits ist das wichtig, wenn du „semver“ verwendest, um deine Versionsnummern zu vergeben. Das kannst du auf zwei Arten einfließen lassen:
Die erste Möglichkeit ist ein „Ausrufezeichen“ vor dem „Doppelpunkt“ in der Betreffzeile einzufügen. Du erinnerst dich bestimmt daran, als wir über die Betreffzeile gesprochen haben. Die Bezeichnung wird durch ein „Doppelpunkt“ und ein „Leerzeichen“ von Typ und Bereich getrennt. Und genau vor diesem „Doppelpunkt“ setzt du den „Ausrufezeichen“, wenn „Breaking changes“ vorkommen.
Die zweite Möglichkeit ist eine spezielle Fußnote zu verwenden. Du schreibst dann einfach „BREAKING-CHANGE“, gefolgt von einem „Doppelpunkt“, einen „Leerzeichen“ und eine kurze Beschreibung.
