Anatomie eines git Commit-Kommentars

Jeder, der mit dem Versionskontrollsystem git zu tun hat, wird früher oder später feststellen, wie ein Commit-Kommentar aussehen sollte. Für alle, die das bisher noch nicht wissen, hier mal ein kurzes Beispiel:

Kurzer Betreff, max. 80 Zeichen

Optionaler längerer Text, der den Commit beschreibt. Dieser darf gern mehrzeilg
sein und die Beweggründe erläutern.

Optionale Signaturen.

Nun stellt sich die Frage: Warum macht man das so? Dies möchte ich anhand eines praktischen Beispiels erläutern:

mesa: remove '(void) k' lines

Serves no purpose as the k parameter is used later in the code.

In diesem Commit wurden mehrere Codezeilen gelöscht. Hätte der Autor gar keinen Kommentar angegeben, wäre rätselhaft warum er dies getan hat. Glücklicherweise erzwingt git immer eine Commit-Meldung. Aber auch die erste Zeile alleine ist nicht aussagekräftig, sondern folgt dem „stating the obvious“-Prinzip. Man findet damit den Commit leicht wieder, aber man kennt immer noch nicht den Grund. Dies wird erst durch die letzte Zeile klar.

Signaturen

Es gibt in git die Möglichkeit Signaturen in einer Commit-Meldung anzugeben, z.B.:

Signed-off-by: Christoph Brill <webmaster@egore911.de>

Diese dienen dazu, zusätzliche Informationen über die an dem Commit beteiligten Personen anzugeben. Es gibt keinen offiziellen Standard für diese Signaturen, aber folgende haben sich in verschiedenen Projekten als hilfreich erwiesen:

  • Signed-off-by: Der Commit wurde durch den Signierenden in die Repository aufgenommen. Diese Meldung dient mehr oder weniger als zusätzliche Autorenangabe
  • Reviewed-by: Der Commit wurde vom Signierenden durchgesehen und für sinnvoll befunden
  • Tested-by: Der Signierende hat den Commit in seinem lokalen Sourcecode eingespielt und getestet.

Verwendung im Alltag

In einer idealen Welt würde jeder detaillierte Kommentare (sowohl im Code als auch in Commit-Meldungen) verwenden. Die Praxis zeigt jedoch, dass dies nicht immer zutrifft. Selbst disziplinierte Projekte werden Commits aufweisen, die weit von diesem Ideal abweichen. Git (wie andere Versionskontrollsysteme auch) erlaubt es allerdings mit minimal strukturierten Commit-Meldungen anderen Entwicklern (oder dem Entwickler selbst zu einem späteren Zeitpunkt) den Commit zu verstehen, ohne jede Zeile Code des Commit gelesen zu haben.

Copyright © christophbrill.de, 2002-2017.