Commit Messages – Eine Agile Art der Dokumentation

Mittlerweile sind schon viele Commit Messages an mir vorbei gegangen. Daraus hat sich ein gewisses Prinzip für mich entwickelt, was ganz gut klappt für mich.

1. Immer eine Meldung schreiben

Egal was man in die Versionsverwaltung packt, immer einen kurzen Text, welche die Änderungen beschreibt. Hilft ungemein, wenn man etwas wiederfinden will und vor allem, warum etwas einchecken, wenn es keinen Grund gibt ?

2. Häufig commiten

Weniger direkt mit Commit Messages zu tun, aber sobald mit „und und und“ arbeitet bei der Commit Message. Sollte man sich wohl seinen commit nochmal überlegen, ob man ihn nicht aufspaltet.

3. Kurzer Header und eine Beschreibung

Meine Texte bestehen mittlerweile meist aus zwei Teilen, einer kurzen Beschreibung der Änderung. Und eine detailierte Beschreibung, was man dort geändert hat. Auf diese Art entwickelt sich eine einfache Dokumentation, welche dabei auch bei Änderungen überschrieben wird und dadurch auch nicht veraltet, wie ein ungepflegtes Textdokument.

4. Aufgaben IDs

Jeder hat irgendein System für die Aufgabenverwaltung, sei es der Team Foundation Server, Youtrack,… .
Meist gibt es dort auch eine entsprechende ID, welche man am besten in der Commit Message direkt integriert, als #1. Änderungen sind so leicht mit einer entsprechenden Aufgabe in Verbindung zu bringen.

Ein Beispiel

#1 – Rote Liste wird als extra Mandant übertragen

Die Rote Liste wird nun als Mandant „X_RoteListe“ übertragen. Der Mandant enthält daher den entsprechenden Identifier zur Rote Liste Datenbank.

Fazit

All das hilft jetzt für die Programmierung nicht sehr viel. Aber für jeden der im Nachhinein mit dem Quellcode zu tun hat, sei es ein Entwickler, der etwas ändern muss oder auch ein Tester, welcher sich fragt, was diese Änderungen eigentlich grade tut.

Kommentar verfassen