Conventional Commits

Datum: Januar 2021
Lesedauer: 3 Minuten

add new modifier
improve hbs file
work on heading
improve code

Diese Commits habe ich in meinem Repository gefunden. Es ist klar, dass diese Messages nicht optimal gewählt wurden.
Doch wie sollen diese geschrieben werden? Ist diese Message überhaupt wichtig?

Vorteile

Es gibt Regeln im Bezug auf diese Messages. Mehr über diese Standardisierung kann man hier (opens in a new tab) nachlesen.

Folgende Vorteile ergeben sich, wenn man diese einhält:

Die Messages sind Einheitlich (gerade im Team ist das hilfreich)
Commits können einfacher sortiert werden
Man sieht immer genau, wozu ein Commit gemacht wurde
Sucht man einen Commit, so helfen einem die Kategorien

Struktur

Eine Commit-Message soll so aufgebaut sein:

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

Type

Über den Type wird definiert, um was für eine Veränderung es sich handelt. Dazu stehen einem folgende Optionen zur Verfügung.

Type	Beschreibung	Beispiel
build	extern dependencies	install npm
ci	CI changes	build the site
docs	documentations	add setup information to the readme
feat	new feature	button can now open a new page
fix	fixed bug	accordion can be folded up again
perf	change in code which impacts the performance	swap part of a code into function
refactor	change in code which neither fixes a bug nor is a feature	rename variable
style	changes that do not change functionality from code	format JS file, remove spacing and add semicolons
test	add or improve tests	write a cypress test

Sind die Commits klar Kategorisiert, erleichtert dies später das sortieren.

Revert

Wenn der Commit einen anderen rückgängig macht, so soll dies ebenfalls im Type gekennzeichnet werden. Zusätzlich macht es Sinn, den SHA von dem alten Commit in die Nachricht einzubauen. Ein revert Commit könnte also so aussehen:

revert: this reverts commit cba73d9466f2081c450397e45529903126de25c8

Scope

Im Scope schreibt man, um welchen Branch es sich handelt. Beispiele könnten sein:

(homepage)
(image)
(stage)

In GitLab kann man die Tickets schon nach Branch sortieren. Nach einem Merge Request ist die Herkunft eines Commits jedoch nicht direkt ersichtlich. Deshalb ist es empfehlenswert, dieses optionale Scope anzugeben.

Description

Hier kann man beschreiben, was man gemacht hat. Wichtig:

Man schreibt immer in der Gegenwart
Buchstaben werden klein geschrieben
Selbst wenn es ein Satz ist, verwendet man kein Punkt am Ende

Tipp: Eine solche Nachricht sollte ca. 50 Zeichen betragen.

Body

Im Body geht man auf den Grund der Veränderung ein. Zudem kann man genauer beschreiben, was sich verändert hat. Ansonsten gelten die selben Regeln wie in der Description.

Footer

Bei schwerwiegenden Veränderungen kann hier auf das Issue referenziert werden, welches mit dem Commit geschlossen wird. Solche Veränderungen werden jeweils mit BREAKING CHANGE oder einem ! gekennzeichnet.

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

Man kann einen Breaking Change auch mit einem ! kennzeichnen.

refactor!: drop support for Node 6

Beispiel

So könnten also deine zukünftigen Commits aussehen.

docs(image): write a new readme for the img pattern

this pattern without a readme would not be useful

feat(button): add new functionality to open the overlay

BREAKING CHANGE: change the script language form js to ts

Commit Linting

Wie kann ich sicherstellen, dass ich mich an die Regeln halte?
Es gibt es unzählige npm Pakete, welche einem dabei helfen. Beispiele:

commitizien: https://github.com/commitizen/cz-cli (opens in a new tab)
commitlint: https://github.com/conventional-changelog/commitlint (opens in a new tab)

Meinung

Das Ziel sollte immer sein, dass ein Commit etwas eigenständiges ist. Zudem darf er nicht zu gross sein. Dies ist mit diesen Regeln gewährleistet, da ein Commit von einem bestimmten Type sein muss.
Man benötigt etwas mehr Zeit, um jeweils diese Commits zu erstellen. Dafür sind sie später verständlicher und man hat eine bessere Übersicht. Gerade das suchen von älteren Commits wird einfacher, da nach einem Typ gefiltert werden kann.
Arbeitet man im Team, so ergibt es Sinn, sich an solche Abmachungen zu halten. So kommt man auch mit den Commits der anderen zurecht.

Ich sehe also mehr Vor- als Nachteile, wenn man die Regeln einhält.