Letzte Änderung am 28. Dezember 2021 by Christoph Jüngling
Manchmal ist es notwendig, Anwendern kurz und bündig mitzuteilen, was sich seit dem letzten Release geändert hat. Wenn man nicht in der glücklichen Lage ist, dass ein ALM-System einem diese Arbeit abnimmt, kann auch die Quellcodeverwaltung von Nutzen sein. Git bietet dazu bereits auf der Kommandozeile einige Optionen. Im konkreten Fall ziehe ich diese sogar vor, da TortoiseGit meines Wissens diese Flexibilität nicht besitzt.
Ich setze voraus (weil ich es so mache), dass jedes Release im Git mit einem entsprechenden Tag (dt. “Marke”) gekennzeichnet ist. Der Übersichtlichkeit halber benenne ich diese mit dem Präfix “release/”, gefolgt von dem kleinen “v” und der Versionsnummer. Das muss nicht so sein, hat aber den Vorteil der leichteren Auffindbarkeit im TortoiseGit, da dieses die Namen am “/” auftrennt und als aufklappbare Hierarchie darstellt.
Weiterhin wissen wir (oder sollten es zumindest), dass die Commit-Message in Git aus einer einleitenden Zeile besteht, gefolgt von einer Leerzeile und dann beliebig viel erklärendem Text. Die Leerzeile und der weitere Text sind optional. Die Konvention für die gesamte Commit-Message ist, dass keine Zeile mehr als 72 Zeichen enthalten sollte. Die erste Zeile ist dabei von besonderer Bedeutung: Sie wird quasi als Überschrift des Commits angesehen und je nach Ausgabeformat vielleicht so gar als alleinige Message verwendet.
So gerne ich mit TortoiseGit arbeite (zumindest unter Windows), für den konkreten Fall dieses Artikels nützt es mir wenig. Ich kann zwar im Log einen Bereich markieren und mit Rechtsklick + „Copy log messages to clipboard“ eben dieses tun. Leider landet dabei nicht nur die erste Zeile, sondern jeweils die gesamte Commit-Message in der Zwischenablage. Diese müsste ich dann bereinigen, was fehlerträchtig und zeitaufwändig wäre. Die Kommandozeile ist da deutlich flexibler. Der folgende Befehl listet beispielsweise von jedem Commit, der nach dem Tag „release/v7.8“ bis zum aktuellen Stand gemacht wurde, nur die erste Zeile auf:
git log --pretty="%s" release/v7.8..HEADMöchte man etwas mitteilsamer sein, können weitere Platzhalter hinzugefügt werden. In diesem Beispiel wird noch der Hash, das ISO-Datum und der Name des Autors ausgegeben:
git log --pretty="%h %aI %an %s" release/v7.8..HEADSoll es ein bestimmter Commit-Bereich sein, sind natürlich auch zwei Tags möglich:
git log --pretty="%h %aI %an %s" release/v7.8..release/v7.9Wenn man irgendwann die richtige Formatierung gefunden hat, wäre es super, diese zu speichern. Das geht natürlich. Der erste Befehl im nachfolgenden Kasten speichert die Einstellung im userspezifischen Bereich (zu den Bereichen siehe den Artikel Git und seine Einstellungen) und muss natürlich nur einmal eingegeben werden. Der zweite Befehl ruft die gespeicherte Einstellung als Formatierungsanweisung für das „Pretty Print“ ab. Die Zeichenfolge „chris“ steht hier für die Formatierungsanweisung und kann natürlich beliebig geändert werden (solange sie keine Leerzeichen enthält).
git config --global pretty.chris "%h %aI %an %s"
git log --pretty=chris release/v7.8..HEADUnd wenn es noch kürzer sein soll, definieren wir für den git-log-Befehl noch den Alias “mylog” (wieder erst die Definition, dann die Anwendung):
git config --global alias.mylog "log --pretty=chris"
git mylog release/v7.8..HEADNatürlich ließe sich die Formatierungseinstellung auch direkt im Alias unterbringen, also ohne den “Umweg” über die Pretty-Einstellung.
Aber was man bei allem lernt, ist: Vernünftige Commit-Messages schreiben zahlt sich aus :-)
Neueste Kommentare