Sollten Commit-Nachrichten in Gegenwart oder Vergangenheit geschrieben werden? [geschlossen]

Was ist Ihrer Meinung nach besser und intuitiver?

Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY

Bitte geben Sie Ihre Gründe an. Hinweis Ich frage aus Ihrer allgemeinen Perspektive, was bedeutet, dass Sie nicht versuchen sollten, dies mit Ihren bevorzugten SVN / CVS-Tools oder Programmiersprachen zu verknüpfen, sondern es als etwas betrachten, das auf alle Tools und Programmiersprachen angewendet werden sollte / kann.

Ich denke an diese Nachrichten, wie sie anderen Entwicklern erscheinen. Die Änderungen wurden noch nicht angewendet, und es gibt die implizite Frage: "Was bewirkt die Anwendung dieses Änderungssatzes / Patches?" Es wird "den XXX-Fehler in JJJ beheben"!

Für andere Verben scheint das Schreiben als Befehl natürlicher zu sein und funktioniert besser, wenn Sie ein bestimmtes Ziel im Voraus haben. Sie können die Commit-Zusammenfassung zusammen mit den Vorab-Tests buchstäblich schreiben, bevor die Arbeit erledigt ist.

Ich lege nicht viel Gewicht darauf, aber für mich ist dies der Weg des geringsten Widerstands bei gleichzeitiger Wahrung der Beständigkeit.

Ich persönlich gehe in die Vergangenheitsform ("behoben"), da der Fehler behoben ist, wenn ich den Fehler begehen kann (oder ich würde ihn nicht festlegen).

Ich bevorzuge es, Commit-Nachrichten in der Gegenwart zu sehen. Auf diese Weise beschreibt die Nachricht, was der Diff tut (weil Sie diesen Diff oder sogar das gesamte Commit in einen anderen Zweig ziehen könnten). Daher beschreibt die Festschreibungsnachricht nicht, was sie "getan" hat ... Sie beschreibt, was die Festschreibung selbst "tut". So sollte es in der Gegenwart sein.

Stellen Sie sich vor, Sie betrachten einen Unterschied isoliert und versuchen zu entscheiden, ob Sie ihn anwenden. Es macht keinen Sinn, einen Titel in der Vergangenheitsform zu haben.

IMHO, wenn Sie möchten, dass es beschreibend ist, ohne den Kontext berücksichtigen zu müssen, dann ist "Fixed" definitiv die einzig richtige Variante.

In Bezug auf die Intuitivität - wenn ich mir ein Changelog ansehe, werde ich definitiv verstehen, dass Sie den Fehler meinen, der behoben wurde, da ich den Kontext kenne, in dem das Wort verwendet wird, aber mein Gehirn wird ihn viel schneller erkennen, wenn das Wort in diesem Selbst geschrieben ist. Weg angeben.

"Fixing" ist meiner Meinung nach die schlechteste Wahl, da es nicht nur als Beschreibung der Funktionsweise des Patches interpretiert werden kann, sondern auch als Fehlerstatus, der bedeuten würde, dass daran gearbeitet wird und noch nicht gelöst ist.

Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc

Im Allgemeinen: {Imperativverb} das {betroffene Objekt} {optionale Qualifikationsmerkmale}

Die zwingende Form passt zu allen Anwendungsfällen, wenn ich ein Patchset in Betracht ziehe.

• Was wirst du hier machen?
• Was macht dieses Patchset?
• Warum wurde dieses Patchset erstellt? (um den xxx Fehler zu beheben ...)
• Ich muss den xxx-Fehler in yyy beheben. Gibt es ein Commit für einen anderen Zweig, der dies bereits tut?

Unabhängig von Ihrer Wahl finde ich, dass Konsistenz die Lesbarkeit immens verbessert. Wählen Sie eine und bleiben Sie dabei.

Ich denke, dass das Schreiben über das aktuelle Commit in der Gegenwart eine gute Idee ist, da es klarer wird, wenn Sie auf frühere Commits in der Vergangenheitsform verweisen.

Ich denke nicht, dass es wirklich wichtig ist. Der Zweck ist:

1) Vermitteln Sie, was getan wird oder wurde, damit Fehler leichter gefunden werden können, Probleme leichter behoben werden können und das Projekt im Allgemeinen einfacher gewartet werden kann.

2) Übermitteln Sie, welche Tickets gegebenenfalls repariert wurden, damit Prüfer (wenn sie in Ihrem Unternehmen verwendet werden, sehen können, welche Änderungen welchen Tickets entsprechen).

Wenn es bereits behoben wurde, macht "Fixing" keinen Sinn, und wenn Sie noch daran arbeiten, ist "Fixed" nicht korrekt.

" Fix Bug X " ist 2 Zeichen kürzer als " Fixed Bug X ".
Und 3 kürzer als " Fixing Bug X ".

Unter dem Gesichtspunkt des Schreibens von Short-Commit-Nachrichten speichert die Gegenwart manchmal / normalerweise einige Zeichen?
Was meiner Meinung nach ein wenig wichtig ist, z. B. mit Gits Empfehlung, weniger als 50 Zeichen in der ersten Commit-Nachrichtenzeile zu verwenden.
Auch weniger Text -> schneller gelesen?

Eine Festschreibungsnachricht beschreibt, warum Sie den Code geschrieben haben, der festgeschrieben wird.

"Problem 3124 behoben" oder "Problem 3124 behoben" scheint richtig zu sein, da dieser Code das Problem 3124 behoben hat.

Die Grammatik kann jedoch auch davon abhängen, warum der Fehler als behoben markiert wird. Wenn Sie den Fehler nach dem Festschreiben als behoben markieren können, ist "Behoben" in Ordnung. Wenn der Fehler jedoch von einer anderen Person als behoben markiert wird, nachdem diese Ihren Code überprüft hat, sind "Korrekturen" möglicherweise besser geeignet.

Ich denke, die wichtigste Antwort auf eine solche Frage lautet: Jeder sollte das verwenden, was für ein bestimmtes Projekt funktioniert, und es zumindest ein kleines bisschen konsistent halten.

Obwohl ich die Vorteile der Verwendung der Gegenwart sehe (und tatsächlich auf diesen Beitrag gestoßen bin, weil ich einige Nachrichten der Gegenwart in Open Source-Projekten gesehen habe), werde ich die Gegenwart wahrscheinlich nie für meine Projekte verwenden. Es ist der empfohlene Weg für Linux und Git und wahrscheinlich auch für andere größere Open Source-Projekte, aber es ist mir ehrlich gesagt egal, solange ich nicht Teil dieser Projekte bin.

Ich bin ein Indie-Entwickler und verwende die erste Zeile einer Commit-Nachricht für Versionshinweise, während die Beschreibung in den folgenden Zeilen mir eine Vorstellung von Implementierungsdetails gibt. Es ist ein benutzerzentrierter Workflow im Vergleich zum gegenwärtigen, entwicklerbasierten Ansatz. Auf diese Weise kann ich Zeit sparen. Es wäre äußerst unnatürlich, meinen Benutzern Anweisungen in den Versionshinweisen zu geben. Es ist meine Aufgabe, Fehler zu beheben und Funktionen hinzuzufügen. Ich muss Zeit sparen, weil ich ein Indie bin. Ich habe keinen "Release Notes Writer" in meinem Team.

Verwenden Sie die Regeln eines Projekts, wenn diese bereits festgelegt sind, bleiben Sie jedoch pragmatisch und tun Sie alles, was Ihre Arbeit einfacher oder schneller macht.

Ich denke, es "Fixes XXX bug"ist sinnvoller, als "Fix XXX bug"wenn der Grund für die Verwendung der Gegenwart darin besteht, "beschreibender zu machen, was das Commit tut", als was der Committer getan hat.

Wenn es sich um ein kleines Commit handelt, verwende ich Present Continuous:

Fehlerbehebung 304

oder

Kommentare hinzufügen

Wenn es sich um ein großes Commit handelt, mache ich eher ein Änderungsprotokoll:

• Behebt die Fehler 453, 657 und 324
• Ausdruckssyntax hinzufügen
• Die Operator-Klasse wurde überarbeitet.