Intro
Wenn du mit git arbeitest, kennst du mit Sicherheit die Pflichtnachricht, die bei jedem Commit dazu gehört. Andere Tools verwenden auch solche Nachrichten. Wichtig ist, dass ein Text mitgeschickt wird, um die Änderungen zu beschreiben. Das ist die Commit-Nachricht. Für manchen ist das ein notwendiges Übel, andere finden es sinnvoll und hilfreich. Ich gehöre eher zu der zweiten Fraktion.
Gute Commit-Nachrichten bringen uns größere Vorteile und wir sollten diese auch nutzen. Dafür eignen sich einige Konventionen gut, welche uns am Ende des Tages die Arbeit erleichtern. Aber lass mich euch von einer Situation erzählen, dass wir in meinem Team vor nicht allzu lange Zeit hatten.
Eine kleine Geschichte
Es war Dezember. Wir hatten vor kurzem ein neues Projekt gestartet und wollten nicht während die Weihnachtszeit alles liegen und stehen lassen. Also haben wir hin und her getrickst und den Urlaub so gelegt, dass jederzeit mindestens eine von uns in der Arbeit war. Zwischen Weihnachten und Sylvester war nur Kollege eingeteilt.
Dann war es so weit, die Woche kam und da stand er und wollte mit der Arbeit beginnen. Wir hatten ihn natürlich, mündlich oder per E-Mail, die eine oder andere Information bereits mitgeteilt. Der Stand der Entwicklung war also klar.
Weit gefehlt. Wir hatten nicht so sauber gearbeitet, wie wir dachten. Festzustellen welche Tickets bearbeitet werden können und welche nicht, war wohl schwieriger, als wir gedacht hätten. Da war er voller Elan und stellte fest, „Hoppla, ich weiss doch gar nicht wo ich anfangen soll“. Es hat ihm Zeit und Mühe gekostet, die nötige Infos herauszufinden. Wie du dir vorstellen kannst, das macht nicht wirklich schneller.
Nach dem Urlaub, als wir alle wieder da waren, hat er uns erzählt, welche Schwierigkeiten er gehabt hatte. Sofort war uns klar: Hier ist Verbesserungspotenzial. Eine der Sachen, die wir als Team erreichen möchten, ist das jederzeit, ein Teamkollege für uns einspringen kann, wenn es notwendig ist.
Er hat uns erklärt, „Ich habe versucht in Erfahrung zu bringen wo ich ansetzen kann. Als ich die Tickets und deren Commit Historie geprüft habe, ist mir aufgefallen, dass der Informationsgehalt sehr dürftig war und ich nicht genau wusste was alles passiert war. Das hat mich dazu gezwungen, den Code durchschauen zu müssen, um es rauszufinden“.
Leider hatte er recht. Unsere Commits waren alles andere als optimal. Wir hatten uns keine Konventionen dafür gegeben, so dass jeder von uns anders formatiert und geschrieben hat, was ihm gerade in den Sinn kam. Wir haben uns entschieden, die Qualität unsere Commit-Nachrichten in die Höhe zu treiben. Die Commit-Historie muss uns helfen, zu verstehen, was im Projekt geschieht, ohne im Code nachschauen zu müssen. Versteht mich nicht falsch, im Code zu schauen ist völlig ok, aber es soll nicht die einzige Möglichkeit sein.
Wir haben uns Rat geholt. Sowohl aus alte Erfahrungen wie auch vom Internet. Sind dann in uns gegangen und haben einige Mittel gefunden, um die Umstände zu verbessern. Eins davon ist „Conventional Commits“.
Nun haben wir diese Konventionen umgesetzt. Das ist nicht immer leicht. Wir kämpfen immer wieder mit dem inneren Schweinehund und die alten Gewohnheiten. Es ist nicht leicht, etwas zu ändern aber nach einiges Hin und Her ist es uns gelungen. Ich bin froh, dass wir diesen Weg gegangen sind. Unsere Commit-Nachrichten sind aufgeräumter, einheitlich formatiert und der Informationsgehalt ist deutlich besser geworden.
