Git ist eines von vielen Werkzeugen eines Softwareentwicklers, welches unerlässlich ist. Doch, wie bei Werkzeugen üblich, ist die korrekte Verwendung ebenso unerlässlich. Git ist ein Versionsverwaltungssystem. Es ermöglicht die kollaborative Zusammenarbeit an einem Projekt, die Erstellung von mehreren Versionen des Projektes, und ermöglicht das Einsehen und Widerherstellen alter Versionen. Die verschiedenen Versionsstände werden als Commits bezeichnet. Ein Commit ist eine Reihe von Änderungen, welche an dem Projekt vorgenommen wurden. Der Commit ist mit einer Commit-Message versehen, welche erklären soll, was sich mit diesem Commit verändert hat. Soweit die Theorie… Nun ist es in der Praxis leider oft so, dass Commit-Messages eher weniger aussagekräftig sind. Darunter fallen Commit-Messages, wie „wip“ oder „changes“. Oft kommen solche Commit Messages gepaart mit ellenlangen Änderungen. Wer im Nachhinein versuchen möchte diesen Commit nachvollziehen, wird sich schwarzärgern, dass der Commit so unverständlich ist. Und genau dieses Problem soll im Folgenden thematisiert werden.
Warum sind gute Commit-Messages so wichtig?
Aber fangen wir erstmal von vorne an. Warum würde man sich im Nachhinein überhaupt die Commits ansehen wollen? Warum ist es also so wichtig gute Commits zu schreiben. Nun, zuallererst beinhalten viele Workflows in der Softwareentwicklung das Review eines zweiten Entwicklers. Dieser zweite Entwickler muss sich die Änderungen ansehen, sie nachvollziehen und validieren, dass die Änderungen das tun, was sie beabsichtigen. Um zu verstehen, was die Änderungen beabsichtigen, wäre es nun hilfreich, aussagekräftige Commit-Messages als ersten Anhaltspunkt zu haben. Natürlich kann ein Blick in das Ticket nicht schaden, welches mit den Änderungen gelöst werden soll, aber auch das muss ja irgendwie aus dem Merge Request oder den Commits hervorgehen. Der erste Grund, warum sinnvolle Commit-Messages wichtig sind, ist also folgender:
Git-Commit-Patterns
Aus Commit-Messages soll ersichtlich sein, was der Autor mit seinen Änderungen beabsichtigt. Um die Absichten des Autors nachzuvollziehen, wird der Kontext benötigt, also die Ticketnummer. Sie sollte also bestenfalls in jedem Commit stehen. Nun soll auch die Commit-Message verständlich sein. Aber wie kann man große Änderungen an vielen verschiedenen Dateien sinnvoll in ein paar Wörtern zusammenfassen? Es funktioniert nicht. Daher müssen Commits kleinteilig sein. Atomar. Wenn sich eine Änderung nicht einfach in einer Commit-Message verpacken lässt, dann ist das ein Zeichen dafür, dass die Änderungen noch nicht weit genug heruntergebrochen wurden. Um dieses Herunterbrechen zu erleichtern, kann es helfen, Commits in verschiedene Kategorien einzuteilen. Die Einteilung von Änderungen in Kategorien hilft beim Herunterbrechen des Commits im Allgemeinen. Im Folgenden ist eine Liste mit Kategorien, welche sich für mich vielfach als sinnvoll erwiesen haben. Dabei sei angemerkt, dass ich diese Liste einem anderen Post entnommen und in meinen Workflow integriert habe:
- build: Alles, was mit builds zu tun hat
- ci: Alles, was mit Pipelines zu tun hat
- docs: Dokumentation angepasst
- feat: Ein neues Feature implementiert
- fix: Einen Bug gefixt
- perf: Code angepasst, um die Performance zu verbessern
- refactor: Durchgeführte Refactorings
- revert: Code revertet
- style: Formattierung etc. angepasst
- test: Tests hinzugefügt oder angepasst
- chore: Verbesserung der Coding-Experience
Eine einfache Konvention zum Schreiben von Commit-Messages unter
Verwendung von Kategorien kann wie folgt aussehen:
<Name des Refactorings>: <Details zum Refactoring>.
Näheres zu dieser Konvention wird in diesem Dev.to-Post
beschrieben.
Gitmojis
Es bietet sich in dem Rahmen von Git Commit-Patterns auch an Gitmojis zu verwenden. Gitmojis sind
Emojis für Commit-Messages. Sie legen für die zuvor aufgelisteten
Commit-Kategorien, sowie weitere Kategorien, einen Emoji fest, welcher
die Kategorie repräsentiert. Damit lässt sich die Kategorie eines
Commits schneller und einfacher erkennen. Bei Verwendung von Gitmojis
bietet sich die folgende Konvention an:
:recycle: <Name des Refactorings>: <Details zum Refactoring>.
Die Verwendung von Konventionen hat den Vorteil, dass Commit-Messages im
Nachhinein einfacher zu verstehen sind. So können die Commits, durch
welche Bugs in den Code gekommen sind, einfacher identifiziert werden.
Gitmojis sorgen für eine einheitliche Kategorisierung von Commits. Es
ist schnell ersichtlich, zu welcher Kategorie ein Commit gehört. Die
einzelnen Kategorien zwingen außerdem den Autor dazu, seine Commits so
stark aufzuteilen, bis diese zu einer Kategorie passen. So wird
sichergestellt, dass ein Commit nicht zu viele Änderungen auf einmal
macht.