Über Commits und Commit-Nachrichten
Die Commit-Historie ist die Summe aller Commit-Nachrichten im Projekt. Sie ist ein Werkzeug der Entwicklung, denn sie hilft uns zu verstehen, wie das Projekt fortschreitet. Sie zeigt uns, was sich geändert hat, wie es sich geändert hat und warum. Sie verrät uns, welche neue Funktionalität dazu gekommen ist und welchen Mehrwert wir damit geschaffen haben. Sie ist nützlich, wenn wir in einem neuen Projekt einsteigen oder auf Fehlersuche sind oder einen Review vornehmen möchten.
Ich habe in meinem Leben viel zu viele grässliche Commit-Nachrichten gesehen. Ja, sogar manche selbst geschrieben. Es ist nötig, auch dort eine gewisse Qualität einfließen zu lassen. Aber wie definiere ich ein schlechten Commit. Hier ein paar Beispiele, die ich gesehen habe, oder mir erzählt worden sind:
- Einfach ein Leerzeichen, sonst nichts.
- Einen Punkt, um halt was rein zu tun, die Nachricht darf ja nicht leer sein.
- Einfache Texte wie „Klasse hinzugefügt“ oder „Button Position angepasst“.
Was soll ich daraus erfahren? Was sagen mir diese Nachrichten? All diese Beispiele sind schrecklich. Sie beinhalten kaum relevante Informationen und helfen uns nicht zu verstehen, was wirklich passiert ist.
Wie sieht es also eine Commit-Nachricht aus, die den Namen auch verdient? Welche Informationen gehören darin?, Wie formatiere ich sie? Alles gute Fragen, auf die wir jetzt eine Antwort erfahren sollten. Schau mal in eine meine nächsten Artikel nach.
Commit-Größe
Ein weiterer Punkt bringt mich zum Grübeln, und zwar, weil ich das Problem selbst habe. Meine Commits sind manchmal viel zu groß. Aber was bedeutet eigentlich viel zu groß? Na ja, ganz einfach, entweder habe ich mehrere Änderungen auf ein Mal hinzugefügt oder die Änderung war von vorne rein viel zu wuchtig.
Das Erste vermeiden wir, indem wir darauf achten, dass Anpassungen, die nicht miteinander zu tun haben, in getrennte Commits zu packen. Das bedeutet ein Commit; eine Änderung. Nicht mehrere Änderungen in ein Commit. Das hilft dabei sie kleiner zu halten.
Das Zweite kann ein vorgelagertes Problem sein. Tickets mit zu viel Inhalt. Das führt dazu, dass viele Anpassungen nötig sind, um das Ticket zu bearbeiten. Dann müssen wir eben das Ticket in Kleinere aufteilen. Kleinere Tickets, die voneinander abgetrennt sind. Damit sind wir das Problem los.
Und was ist, wenn das Ticket nicht geteilt werden kann? Das höre ich öfters, obwohl ich mir nichts immer erklären kann, warum es nicht möglich sein soll. Na ja, egal. Auch dann haben wir die Möglichkeit, nicht alles auf einmal zu committen, sondern die Commits aufzuteilen, so wie wir mit den Anpassungen vorankommen. Heißt, wir machen ein paar Anpassungen und wenn sie eine abgeschlossene kleine Einheit bilden, setzen wir den Commit ab und arbeiten dann weiter.
Um es auf dem Punkt zu bringen, nutze liebe kleinere unabhängige Commits anstatt großere mit verschiedenen Abhängigkeiten.
