Nachrichten richtig übermitteln

Wir haben es alle schon erlebt. Sie sehen etwas in Ihrem Quellcode. Sie wissen nicht, warum es hinzugefügt wurde. Und Sie sehen sich den Commit-Verlauf an. Und dann sehen Sie: "Fehler beheben" oder "Funktion hinzufügen". Wie hilfreich ist diese Nachricht?

In diesem Blogbeitrag werde ich darauf eingehen, wie Sie Commit-Nachrichten schreiben können, die hilfreich sind. Und für den Leser optimiert sind.

Warum ist das also wichtig?

Die meisten agilen Teams brauchen Peer Reviews. Der gängigste oder bekannteste Weg ist der über Pull Requests.Wenn Sie eine Änderung einführen. Für eine Funktion oder die Behebung eines Fehlers.

Die Frage, die Ihr Peer Reviewer stellen wird, lautet: Warum wurde diese Änderung vorgenommen. Und fährt dann fort, sich die Änderungen anzusehen.

Sie erstellen eine Pull-Anfrage auf eine oder mehrere Commit-Nachrichten. Ein Commit beschreibt das Warum einer Änderung. Wenn Sie eine Pull-Anfrage erstellen, können Sie diese Commit-Meldungen verwenden, wenn Sie Ihre Pull-Anfrage erstellen.

Beispiel-Commit

Eingabe fixieren

Oder:

Fix: Leerzeichen bei der Eingabe Entfernen Sie die führenden und nachgestellten Leerzeichen. Damit wird die Eingabe bereinigt, bevor wir sie in der Datenbank speichern. Ausgabe: #123

Das ist der Unterschied zwischen dem Schreiben einer Commit-Nachricht. Und dem Schreiben einer nützlichen Commit-Nachricht. Nützliche Commit-Nachrichten erklären, warum die Änderung vorgenommen wurde.

Wenn Sie einen Pull Request erstellen, können Sie die Commit-Meldungen als Input verwenden. Und entwerfen Sie eine nützliche Pull Request-Beschreibung für Ihren Prüfer.

Format festlegen

Ich bin ein großer Fan des herkömmlichen Commits-Formats. Aber das Wichtigste ist, dass Sie aufschreiben, warum die Änderung vorgenommen wurde. Nicht, was die Änderung ist.

Die Änderungen werden bereits angezeigt, wenn Sie eine diff zwischen Commits/Abzweigungen durchführen. Es macht also keinen Sinn zu beschreiben, was sich geändert hat.Der Grund dafür liegt im Kopf des Autors. Und wenn Sie es nicht in einer Commit-Nachricht hinzufügen, geht diese Information verloren.

Auf diese Weise schaffen Sie einen besseren historischen Überblick. Und es macht es einfacher, Pull Requests zu erstellen.

Fazit

Wenn Sie Ihre Commit-Nachrichten für den Leser optimieren. Der Leser muss sich nicht auf eine Schnitzeljagd begeben. Und es entsteht ein besserer historischer Überblick darüber, warum in Ihrem Repository Änderungen vorgenommen wurden.