Antworten:
Tools zur Versionskontrolle sind leistungsstark genug, um der Person anzuzeigen, welche Dateien geändert und welche Methoden hinzugefügt wurden. Dies bedeutet, dass im Allgemeinen Protokollnachrichten, die bereits vorhandene Nachrichten eindeutig duplizieren, das Protokoll verschmutzen.
Sie haben eine somefuncMethode hinzugefügt , um eine Anforderung zu erfüllen, dh:
Dies bedeutet, dass Ihre Protokollnachrichten vielmehr erläutern müssen, welche Funktionen / Fehler betroffen waren oder wozu das Refactoring diente.
Vergessen Sie nicht, TICKET / AUSGABENUMMER hinzuzufügen .
Wenn Sie ein Feature- oder Issue-Tracking-System mit einer Ticket- oder Issue-Nummer haben , müssen Sie diese ID-Nummer in das Commit einfügen. Dies hilft jedem, der mehr über die Funktion oder das Problem wissen möchte, an dem Sie gearbeitet haben.
In meinem letzten Projekt gab es ein Makro, das entwickelt wurde, um sicherzustellen, dass die ersten 7 Stellen des Kommentars eine gültige Ausgabenummer von clear quest (unser System zur Verfolgung von Problemen / Funktionen) sind.
Ich mache so etwas, wenn ich z. B. das Update für einen Fehler feststelle, bei dem Änderungen an mehreren Dateien erforderlich sind. Auf diese Weise können Sie leichter erkennen, was sich tatsächlich geändert hat, ohne einzelne Dateien im Änderungssatz zu betrachten.
Bei Änderungssätzen für einzelne Dateien ist dies nicht erforderlich.
Die erste Zeile ist immer eine allgemeine Beschreibung des Änderungssatzes, z. B. ein Link zum Fehler oder zur User Story.
Wenn es sich um relevante Informationen in der Beschreibung der Festschreibungsnachricht handelt, geben Sie diese an. Wenn die einzige Information der Dateiname selbst ist, dann nein.
Dies ist beispielsweise sinnvoll: "Die build_foo () - Funktion wurde von fooutil.c nach foobase.c verschoben, da die meisten Programme, die build_foo () verwenden möchten, foobase.c bereits enthalten."
Dies funktioniert nicht: "Build_foo () in fooutil.c wurde aktualisiert, um einen Balkenparameter zu übernehmen."
Ich möchte hier eine andere Perspektive hinzufügen.
Meine Antwort ist Ja oder Nein. Aber im Allgemeinen würde ich Ja sagen.
Die Versionskontrolle ist in der Tat leistungsfähig genug, um zu wissen, welche Datei aktualisiert wird. Aber wenn wir das tun
$ git log
Wir sehen nur die Commit-Nachricht. Das machen die meisten Leute.
Indem Sie in das Protokoll selbst schauen. Es wird ein zusätzlicher Kontext hinzugefügt. Zum Beispiel:
readme.md: Fix typo detected by language tool
Ist besser als
Fix typo detected by language tool
Wenn die Änderungen jedoch mehrere Dateien erzeugen, erwähnen Sie mindestens die Komponente, die bearbeitet wird.
API: Fix reset password not sent email to user
Durch das Lesen wissen wir, dass der behobene Fehler in der API-Komponente und wahrscheinlich im API-Verzeichnis in der Codebasis liegt.
Wir könnten es jedoch tun
$ git show COMMIT_ID --name-only
aber es fügt mehr Schritt hinzu, nur um die Dateien zu erhalten.
Das einzige Mal, dass ich sehe, dass dies für das Einchecken einer einzelnen Datei nützlich ist, ist, wenn Sie Änderungen an einer Funktion vorgenommen haben, die an vielen Stellen in der Datei verwendet wird, so dass das Diff überladen ist. Sogar dann würde ich zuerst die Änderungsverfolgungsnummer und eine Klartextbeschreibung der Änderung einfügen.
Ich denke, die eigentliche Frage hier ist, wie begrenzt der Umfang Ihrer Verpflichtungen ist. Wenn Sie darauf warten, eine Vielzahl von nicht zusammenhängenden Änderungen in einem Commit festzuschreiben, müssen Sie möglicherweise angeben, welche Dateien zu welchem Zweck geändert wurden.
Wenn Sie jedoch einfach häufiger engere Festschreibungen vornehmen, wird durch eine einzelne Festschreibung erläutert, welche Dateien geändert wurden, und Sie können einfach beschreiben, wozu die Nachricht dient.
Immer häufiger. Auf diese Weise können Sie vermeiden, dass Ihre Nachrichten so ausführlich sind.