Sollte ich in Git-Commit-Nachrichten die Vergangenheits- oder die Gegenwartsform verwenden?

Question

I einmal lesen dass Git-Commit-Nachrichten in der imperativen Gegenwartsform verfasst sein sollten, z. B. "Füge Tests für x hinzu". Ich verwende jedoch immer die Vergangenheitsform, z. B. "Added tests for x", was sich für mich viel natürlicher anfühlt.

Hier ist eine aktuelle Verpflichtung von John Resig die beide in einer Nachricht enthalten sind:

Tweak einige mehr jQuery gesetzt Ergebnisse in der Manipulation Tests. Außerdem wurde die Reihenfolge der erwarteten Testergebnisse korrigiert.

Ist das wichtig? Welche sollte ich verwenden?

Answer 1

Die Vorliebe für Commit-Nachrichten im Präsens und im imperativen Stil kommt von Git selbst. Von Dokumentation/Einreichung von Patches im Git Repo:

Beschreiben Sie Ihre Änderungen im Imperativ, z. B. "make xyzzy do frotz" anstelle von "[Dieser Patch] lässt xyzzy frotzeln" oder "[Ich] habe xyzzy frotz", als ob Sie der Codebasis Befehle erteilen, ihr Verhalten zu ändern ihr Verhalten zu ändern.

Sie werden also viele Git-Commit-Nachrichten in diesem Stil sehen. Wenn Sie in einem Team oder an Open-Source-Software arbeiten, ist es hilfreich, wenn sich alle an diesen Stil halten, um Konsistenz zu gewährleisten. Selbst wenn Sie an einem privaten Projekt arbeiten und der Einzige sind, der Ihre Git-Historie jemals sehen wird, ist es hilfreich, die imperative Stimmung zu verwenden, da sie gute Gewohnheiten etabliert, die bei der Zusammenarbeit mit anderen geschätzt werden.

Answer 2

Ihr Projekt sollte fast immer verwenden Sie die Vergangenheitsform . Aus Gründen der Kohärenz und Klarheit sollte im Projekt auf jeden Fall immer dieselbe Zeitform verwendet werden.

Ich verstehe einige der anderen Argumente, die für die Verwendung des Präsens sprechen, aber sie in der Regel nicht zutreffen. Die folgenden Aufzählungspunkte sind allgemeine Argumente für das Schreiben im Präsens und meine Antwort darauf.

• Das Schreiben im Präsens sagt jemandem was die Anwendung des Commit bewirken wird und nicht das, was Sie getan haben.

Das ist der beste Grund, warum man das Präsens verwenden sollte, aber nur bei der richtigen Art von Projekt. Diese Denkweise betrachtet alle Commits als optionale Verbesserungen oder Features, und Sie können frei entscheiden, welche Commits Sie in Ihrem speziellen Repository behalten und welche Sie verwerfen wollen.

Dieses Argument funktioniert, wenn Sie es mit einem wirklich verteilten Projekt zu tun haben. Wenn Sie es mit einem verteilten Projekt zu tun haben, arbeiten Sie wahrscheinlich an einem Open-Source-Projekt. Und wenn es wirklich verteilt ist, ist es wahrscheinlich ein sehr großes Projekt. In der Tat ist es wahrscheinlich entweder der Linux-Kernel oder Git. Da Linux wahrscheinlich der Grund dafür ist, dass sich Git verbreitet und an Popularität gewonnen hat, ist es leicht zu verstehen, warum die Leute seinen Stil als Autorität betrachten. Ja, der Stil macht bei diesen beiden Projekten Sinn. Oder, im Allgemeinen, funktioniert er mit groß, quelloffen, verteilt Projekte.

Abgesehen davon funktionieren die meisten Projekte in der Versionskontrolle nicht auf diese Weise. Es ist in der Regel für die meisten Repositories falsch. Es ist eine moderne Art, über einen Commit zu denken: Subversion (SVN) und CVS-Repositorien können diese Art von Repository Check-Ins kaum unterstützen. Normalerweise kümmerte sich ein Integrationszweig um das Filtern von schlechten Check-Ins, aber diese wurden im Allgemeinen nicht als "optional" oder "nice-to-have Features" angesehen.

In den meisten Szenarien, wenn Sie Übertragungen an einem Quellcode-Repository vornehmen, schreiben Sie einen Tagebucheintrag, der beschreibt, was sich mit dieser Aktualisierung geändert hat, um es für andere in der Zukunft einfacher zu machen, zu verstehen, warum eine Änderung vorgenommen wurde. Es handelt sich im Allgemeinen nicht um eine optionale Änderung - andere Leute im Projekt sind verpflichtet, diese entweder zusammenzuführen oder neu zu basen. Sie schreiben keinen Tagebucheintrag wie "Liebes Tagebuch, heute habe ich treffen ein Junge und er sagt Hallo zu mir", aber stattdessen schreibst du "Ich traf ein Junge und er sagte hallo zu mir."

Bei solchen nicht-verteilten Projekten werden 99,99% der Zeit, in der eine Person eine Commit-Nachricht liest, zum Lesen der Historie verwendet - die Historie wird in der Vergangenheitsform gelesen. In 0,01% der Fälle geht es darum, zu entscheiden, ob man diesen Commit anwenden oder in den eigenen Zweig bzw. das eigene Repository integrieren soll oder nicht.

• Konsistenz. So ist es in vielen Projekten (einschließlich Git selbst). Auch Git-Tools, die Commits erzeugen (wie Git Merge oder Git Revert), tun dies.

Nein, ich garantiere Ihnen, dass die meisten Projekte, die jemals in einem Versionskontrollsystem protokolliert wurden, ihre Geschichte in der Vergangenheitsform hatten (ich habe keine Referenzen, aber es ist wahrscheinlich richtig, wenn man bedenkt, dass das Argument der Gegenwartsform seit Git neu ist). "Revisions"-Nachrichten oder Commit-Nachrichten in der Gegenwart machten nur in wirklich verteilten Projekten Sinn - siehe den ersten Punkt oben.

• Die Leute lesen die Historie nicht nur, um zu wissen, "was mit dieser Codebasis passiert ist", sondern auch, um Fragen zu beantworten wie "was passiert, wenn ich diesen Commit herausnehme" oder "was für neue Dinge werden in meiner Codebasis aufgrund dieser Commits passieren, die ich in der Zukunft zusammenführen kann oder nicht".

Siehe den ersten Punkt. In 99,99 % der Fälle, in denen eine Person eine Commit-Nachricht liest, geht es um die Geschichte - Geschichte wird in der Vergangenheitsform gelesen. In 0,01% der Zeit wird er entscheiden, ob er diesen Commit anwenden oder in seinen Zweig bzw. sein Repository integrieren soll oder nicht. 99,99% sind besser als 0,01%.

• Sie ist normalerweise kürzer

Ich habe noch nie ein gutes Argument gesehen, das besagt, dass man eine falsche Zeitform/Grammatik verwenden sollte, weil sie kürzer ist. Bei einer Standardnachricht mit 50 Zeichen sparen Sie wahrscheinlich nur durchschnittlich 3 Zeichen ein. Davon abgesehen ist das Präsens im Durchschnitt wahrscheinlich ein paar Zeichen kürzer.

• Sie können Commits konsistenter mit den Titeln von Tickets in Ihrem Issue/Feature Tracker benennen (die keine Vergangenheitsform verwenden, obwohl sie manchmal in der Zukunft liegen)

Tickets werden entweder als etwas geschrieben, das gerade passiert (z.B. die App zeigt das falsche Verhalten, wenn ich auf diese Schaltfläche klicke), oder etwas, das in Zukunft getan werden muss (z. B. der Text wird benötigt eine Rezension des Herausgebers).

Die Historie (d.h. die Commit-Meldungen) wird als etwas geschrieben, das in der Vergangenheit getan wurde (z.B. das Problem war behoben).

Answer 3

Eine ausführlichere Beschreibung habe ich auf 365git .

Die Verwendung des Imperativs im Präsens erfordert ein wenig gewöhnungsbedürftig. Als ich anfing, ihn zu erwähnen, stieß er auf Widerstand. Gewöhnlich nach dem Motto "Die Commit-Nachricht zeichnet auf was ich getan habe". Aber Git ist ein verteiltes Versionskontrollsystem wo es potentiell viele Stellen gibt, von denen man Änderungen erhalten kann. Eher als Nachrichten zu schreiben, die sagen, was man getan hat, sollte man diese Nachrichten als Anweisungen für die Durchführung der Übergabe. Anstatt einen Commit mit dem Titel zu haben:

Renamed the iVars and removed the common prefix.

Nehmen Sie so einen:

Rename the iVars to remove the common prefix

Was jemandem sagt, was die Anwendung der Übergabe bewirkt, und nicht, was Sie getan haben. Wenn Sie sich die Historie Ihres Projektarchivs ansehen, werden Sie außerdem feststellen dass die von Git generierten Nachrichten ebenfalls in dieser Zeitform geschrieben sind - "Merge" nicht "Merged", "Rebase" nicht "Rebased", so dass das Schreiben in der gleichen Zeitform zu schreiben, um die Konsistenz zu wahren. Es fühlt sich zunächst seltsam an, aber es macht aber es macht Sinn (Erfahrungsberichte auf Anfrage erhältlich) und wird schließlich wird es natürlich.

Nach all dem - es ist Ihr Code, Ihr Repository: Legen Sie also Ihre eigenen eigenen Richtlinien und halten Sie sich daran.

Wenn Sie sich jedoch für diesen Weg entscheiden, dann git rebase -i mit dem Umformulierung wäre eine gute Sache, die man prüfen sollte.

Answer 4

Bleiben Sie beim Imperativ im Präsens, denn

• es ist gut, einen Standard zu haben
• es passt zu Tickets im Bug-Tracker, die natürlich die Form "etwas implementieren", "etwas beheben" oder "etwas testen" haben.

Answer 5

Für wen schreiben Sie die Nachricht? Und liest dieser Leser die Nachricht in der Regel vor oder nach der Übergabe selbst?

Ich denke, dass hier aus beiden Perspektiven gute Antworten gegeben wurden, ich würde vielleicht nur nicht behaupten, dass es für jedes Projekt eine beste Antwort gibt. Die gespaltene Abstimmung könnte darauf hindeuten.

d.h. zusammenfassen:

• Die Nachricht ist in erster Linie für andere Personen bestimmt, die sie in der Regel zu einem Zeitpunkt lesen, bevor sie die Änderung angenommen haben: Ein Vorschlag, was die Übernahme der Änderung für ihren bestehenden Code bedeuten wird.

• Die Nachricht ist in erster Linie ein Tagebuch/eine Aufzeichnung für Sie selbst (oder für Ihr Team), aber in der Regel aus der Perspektive, dass Sie die Veränderung angenommen haben und zurückblicken, um zu entdecken, was passiert ist.

Vielleicht wird dies die Motivation für Ihr Team/Projekt fördern, so oder so.