Standard zu folgen, wenn ich git Commit-Nachrichten schreibe

Question

Ich finde mich sehr viele Dateien verwalten (über 60 aber unter 70) und meine Commit-Nachrichten folgen diesem Muster: wenn ich etwas wie layout.css hinzugefügt habe, ist meine Commit-Nachricht "etwas in der Datei layout.css hinzugefügt", und wenn ich etwas entferne, ist meine Commit-Nachricht "etwas aus der Datei layout.css entfernt".

Einige Dateien auf der ganzen Linie, sehe ich meine Commits Futtermittel- und hinzugefügt ... und entfernt ... Nachrichten dominieren. Manchmal erinnere ich mich nicht daran, was ich entfernt oder was ich in layout.css hinzugefügt habe, da ich so viele Änderungen auf einmal durchführe und so habe ich Mühe, eine passende Commit-Nachricht zu erstellen.

Gibt es einen Standard, dem ich folgen sollte, um mir bei meinen Commit-Nachrichten zu helfen?

Answer 1

Wenn Sie gerade beschreiben, was Sie (in technischen noch unscharfe Begriffe wie getan haben "Eine Funktion hinzugefügt"), fügen Sie nicht viel hinzu, was Git bereits im Commit speichert. Stellen Sie sich vor, Sie würden die Commit-Nachricht einige Zeit später lesen; Welche Art von Zusammenfassung würde Ihnen helfen, sich an das Wesentliche zu erinnern/mit anderen Entwicklern zu kommunizieren ?! Der genaue Inhalt hängt von Ihrem Projekt und Ihren Prozessen ab, aber ich finde das eine gute Richtlinie.

daher in erster Linie hinzufügen Kontext (die warum, nicht die wie) mit Ihrer Nachricht begehen (zum Beispiel „frobnize die Nachrichtenpersistenz zu ermöglichen“) statt „hinzugefügt frob() Funktion“). Es ist mehr Aufwand (Sie müssen reflektieren und denken), aber es ist so viel mehr wert. Wenn Sie mehr über dieses Thema erfahren möchten, gibt es eine Fülle von Informationen, zum Beispiel this blog article by Peter Hutterer oder this funny slide.

Answer 2

Git weiß bereits, welche Dateien Sie bei einem Commit geändert haben, es ist sinnlos, sie im Kommentar anzugeben. Sagen Sie zum Beispiel "Fixed Padding Bug" oder "Menü in der Seitenleiste hinzugefügt". Mach es klar, das ist es.

Answer 3

Das 50/72 Modell scheint eine gute Praxis zu sein. h. die erste Zeile sollte 50 Zeichen lang sein und sollte als Kopfzeile dienen. Gefolgt von einem Leerzeichen sollte der zweite Satz von Zeilen in 72 Zeichen eingeschlossen sein und als Zusammenfassung dienen. Hier ist eine SO Frage: Git Commit Messages : 50/72 Formatting, die das gleiche diskutiert.

Hier sind einige abschließende Anmerkungen zu dem Thema:

1. GIT Commit Good Practice
2. A Note About Git Commit Messages
3. Proper Git Commit Messages and an Elegant Git History