Saubere Commit-Messages sind ein wichtiger Bestandteil, im Entwicklungsprozess. Wir nutzen sie zum Beispiel mit git blame, um uns in kürzester Zeit viele wichtige Fragen zu beantworten. Warum wurde der Code hier geändert? Wen kann ich Fragen, wenn mir etwas unklar ist? Seit wann existiert diese Änderung? etc.. You know the drill.

Wie kommt es also, dass wir häufig vor Nachrichten wie diesen stehen? `More fixes` oder `WIP 15094`? Und selbst wenn die Nachrichten aussagekräftig sind, schaffen wir Entwickler es scheinbar einfach nicht uns auf ein Format zu einigen…

Add: some good message
adding clearly stated stuff
add: very descriptive and short message
feat(1456): add something really cool

..., wenn ein genormtes Format unsere Arbeit so viel einfacher macht?

feat: feature described here
feat: another feature is described
refactor: description of refactored code
fix: a clear and short description about the fix

Ein `git log` der so aussieht, kann sich lesen wie ein morgentlicher Newspaper. Während ich den Ersten nichtmal gescheit durchsuchen kann. Sind wir Entwickler einfach zu bequem oder haben wir keine Zeit, um diese Idee in den Arbeitsalltag zu integrieren?

Bei mir ist es, zugegeben, ein bisschen von beidem. Aber zum Glück gibt es eine Lösung, die chaotische Messages unpraktischer und gleichzeitig sinnvolle Nachrichten bequemer macht.   
Conventional Commits "ist eine einfache Konvention, die auf Commit-Nachrichten aufbaut".  Sie bildet eine Grundlage, auf die wir uns alle einigen können. Somit wird uns die lästige Arbeit erspart über genaue Formulierungen der Commits nachzudenken und der Ablauf wird deutlich bequemer und schneller. 

Wirklich hilfreich wird die Konvention durch Tools für sehr viele Programmiersprachen. Diese enthalten Generatoren und Linter für unsere Commits.

Mein persönlicher Favorit ist Commitizen. Commitizen ist ein CLI Tool, welches Conventional Commit konforme Nachrichten erstellt. 

♥ ❯ pip/npm install commitizen
♥ ❯ cz c
? Select the type of change you are committing (Use arrow keys)
 » fix: A bug fix. Correlates with PATCH in SemVer
   feat: A new feature. Correlates with MINOR in SemVer
   docs: Documentation only changes
   style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
   refactor: A code change that neither fixes a bug nor adds a feature
   perf: A code change that improves performance
   test: Adding missing or correcting existing tests
   build: Changes that affect the build system or external dependencies (example scopes: pip, docker, npm)
   ci: Changes to our CI configuration files and scripts (example scopes: GitLabCI)

Als zusätzliches Goodie können wir von Commitizen sogar einen Changelog generieren lassen inklusive Versionsnummer-Management nach SemVer.

Und wenn man nun so viele Änderungen hat, dass ein einziger Commit sich nicht in refactor, fix, usw. zusammenfassen lässt? In dem Fall empfehle ich git add -p

(microphone-drop)