Commit-Messages sind ein wichtiges Mittel der Kommunikation für ein Entwicklerteam. Und Kommunikation ist so ziemlich das wichtigste an Software-Entwicklungsprozessen. Über Commit-Messages kommuniziert ihr nicht nur mit den anderen, sondern auch mit eurem Future Self. Wenn ihr euch euren eigenen Code von letzter Woche, oder auch den von anderen Entwicklerinnen anschaut, kommen typischerweise Fragen auf:
- Was macht das if da?
- Wer hat vergessen den Branch zu updaten?
- Was für einen Impact hatte dieser Change eigentlich?
- Wie soll das den Code gefixed oder verbessert haben?
… und so weiter.
Gegenchecken könnt ihr das über git -blame.
Der Command sagt euch, welche Revision für den Change verantwortlich ist. Das hilft euch aber nur bedingt weiter, wenn ihr dann nicht die zugehörige Git-Commit-Message lest. Für das Verfassen einer Git-Commit-Message gibt es ein paar Regeln, die es euch und eurem Team leichter machen.
Best Practices
Ihr solltet davon absehen, eure Commits über git commit -m
zu commiten. Warum? So habt ihr gleich zu Beginn das Gefühl, eure Commit-Message in den einen Terminal-Command zwängen zu müssen – ein paar Wörter, die man da hinschreibt, damit da halt was steht.
Der Betreff sollte maximal 50 Zeichen lang sein. Danach solltet ihr eine Leerzeile lassen. Schreibt eure Betreffzeile im Imperativ, also [Fix Bug / Refactor feature xy for readability]
. Manche Teams stellen ihrem Betreff ein Prefix voran, zum Beispiel: TASK: Refaktor feature xy for readability
. Damit ist der Imperativ quasi der Default. Seid konsistent in eurer Sprachverwendung. Konsistent dargestellte Informationen können schneller verarbeitet werden, als wenn ihr alles immer wieder paraphrasiert und Synonyme verwendet. Nach der Betreffzeile lasst ihr typischerweise eine Leerzeile, gefolgt von der Beschreibung eures Commits.
Die Beschreibung des Commits darf dann ein bisschen länger sein – dafür hat sich pro Zeile eine 72-Zeichen-Konvention herausgebildet. Darin solltet ihr sogenannte W-Fragen klären:
- Warum ist der Change nötig?
In eurer Antwort solltet ihr darlegen, was von eurem Commit zu erwarten ist. Die anderen werden euch dankbar sein, wenn ihr diese Frage einigermaßen präzise beantwortet.
- Was genau wurde gemacht?
Beschreibt, was genau ihr unternommen habt, um die Änderung der Codebase zu erreichen. Wenn das offensichtlich ist, könnt ihr diesen Teil der Beschreibung natürlich skippen.
- Irgendwelche Side-Effects?
Eine wichtige Frage, die oft übergangen wird. In dieser Sektion der Commit-Beschreibung wird geklärt, ob ihr eventuell zu viele Dinge auf einmal in einem Commit abhandelt. Wenn eure Aufzählung zwei Punkte hat, ist das vollkommen ok, bei fünf oder sechs solltet ihr euch aber fragen, ob euer Commit nicht doch auch Dinge macht, die eigentlich in einen separaten Commit gehören.
Schlussendlich solltet ihr nicht vergessen, das zugehörige Ticket zu verlinken – falls es eins gibt.
tl:dr:
Formal gibt es einige ganz einfache Regeln für gute Git-Commit-Messages:
- Trennt den Betreff durch eine Leerzeile vom Thema.
- Beschränkt euch in der Betreffzeile auf maximal 50 Zeichen.
- Beginnt die Betreffzeile mit einem Großbuchstaben.
- Ans Ende der Betreffzeile kommt kein Punkt.
- Schreibt eure Betreffzeile im Imperativ.
- Wrappt den Body bei 72 Zeichen.
- Beschreibt im Body das was und warum eures Commits, nicht das wie.
Und euer Lieblings-Git-Commit?
Wer sich an diese Punkte hält, tut seinem zukünftigen Ich und seinem Team einen Gefallen. Inspiration findet ihr zum Beispiel in diesem Blogpost – der Lieblings-Git-Commit des Autors lässt wirklich keine Wünsche offen.