Tim Pope plädiert in seinem Blogbeitrag für einen bestimmten Stil von Git-Commit-Nachrichten: http://www.tpope.net/node/106 .
Hier ist eine kurze Zusammenfassung seiner Empfehlungen:
- Die erste Zeile darf höchstens 50 Zeichen lang sein.
- Dann eine Leerzeile.
- Der restliche Text sollte mit 72 Zeichen umbrochen werden.
In seinem Blogbeitrag werden diese Empfehlungen (die ich der Kürze halber als "50/72-Formatierung" bezeichnen werde) begründet:
- In der Praxis behandeln einige Tools die erste Zeile als Betreffzeile und den zweiten Absatz als Textkörper (ähnlich wie bei E-Mails).
git log
beherrscht keinen Umbruch, so dass es schwer zu lesen ist, wenn die Zeilen zu lang sind.git format-patch --stdout
konvertiert Commits in E-Mail - damit das funktioniert, ist es hilfreich, wenn Ihre Commits bereits schön verpackt sind.
Ein Punkt, den ich hinzufügen möchte und dem Tim wohl zustimmen würde:
- Das Zusammenfassen eines Commits ist eine gute Praxis, die jedem Versionskontrollsystem eigen ist. Es hilft anderen (oder Ihnen später), relevante Commits schneller zu finden.
Ich habe also mehrere Gesichtspunkte zu meiner Frage:
- Welcher Anteil (ungefähr) der "Vordenker" oder "erfahrenen Benutzer" von Git befürwortet den 50/72-Formatierungsstil? Ich frage das, weil neuere Benutzer manchmal die Praktiken der Gemeinschaft nicht kennen oder sich nicht darum scheren.
- Gibt es für diejenigen, die diese Formatierung nicht verwenden, einen prinzipiellen Grund für die Verwendung eines anderen Formatierungsstils? (Bitte beachten Sie, dass ich nach einem sachlichen Argument suche, nicht nach "Ich habe noch nie davon gehört" oder "Es ist mir egal").
- Wie viel Prozent der Git-Repositories sind empirisch gesehen in diesem Stil gehalten? (Für den Fall, dass jemand eine Analyse von GitHub-Repositories durchführen möchte Hinweis, Hinweis.)
Es geht mir hier nicht darum, den 50/72-Stil zu empfehlen oder andere Stile schlecht zu machen. (Um ganz offen zu sein: Ich bevorzuge ihn, aber ich bin offen für andere Ideen.) Ich möchte nur die Gründe erfahren, warum die Leute verschiedene Git-Commit-Botschaftsstile mögen oder ablehnen. (Fühlen Sie sich frei, auch Punkte anzusprechen, die noch nicht erwähnt wurden.)