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


102

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.


Jemand bei Ihrer Arbeit ist zu pedantisch, ich hoffe, Sie sind es nicht. Wer auch immer es ist, sollte das gegenwärtige Perfekt gegen das gegenwärtige Unvollkommene und das philosophische Rätsel betrachten, ob der Commit-Kommentar so gelesen wird, als ob er von dem Zeitpunkt an geschrieben worden wäre oder von dem Zeitpunkt an, an dem er selbst im Repository verblieben ist. In letzterem Fall verwenden Sie Präsens perfekt für eine abgeschlossene Aktion. Wenn erstere, verwenden Sie unvollständig für eine unvollständige gegenwärtige Aktivität.
Heath Hunnicutt

1
Kein Betrüger dieser Frage. Hier geht es um einen kleinen Aspekt, nicht um allgemeine Richtlinien.

3
Zum Glück ist es nicht. Ich habe gefragt, um herauszufinden, möchte wissen, was die allgemeine Praxis da draußen ist. Wenn ich Ihnen die Wahrheit sagen muss, ist dies tatsächlich die unbedeutendste Frage, die ich jemals zu SO gestellt habe, aber hey, es ist immer noch eine Frage, nicht wahr? Die Frage selbst hat drei Stimmen erhalten, was (wenn auch für Sie nicht offensichtlich) zeigt, dass ich nicht der einzige da draußen bin, der denkt, dass diese Frage an sich gültig ist. Ich bin nach konstruktiven Antworten und Sie sind überhaupt nicht hilfreich.
Sein

1
Wenn Sie der Meinung sind, dass sich die Leute nicht zu viele Gedanken über Zeitformen in Commit-Nachrichten machen sollten, sagen Sie es gut, geben Sie Ihre Gründe und Ihre Vorlieben an. Viel nützlicher und hilfreicher als Ihr sarkastischer Kommentar oben.
Sein

10
Ich nehme diese Frage sehr ernst. Es ist eine gute Frage. Bei der Entwicklung von Software ist es sehr wichtig, konsistent zu sein, und dies sollte für alle Besucher von Interesse sein, die sich für das Thema dieser Website interessieren. Das ist meine Meinung.
Niklas Berglund

Antworten:


39

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.


8
Ich erinnere mich, dass ich in der Git-Dokumentation auf etwas gestoßen bin, das diese Zeitform dringend empfiehlt, aber ich finde es immer noch unangenehm.
Keithjgrant

1
Dies ist der Teil der Git-Dokumentation, aus dem er stammt.
Sschuberth

31

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).


Können Sie ein Beispiel dafür geben?
Bzlm

15
ein Beispiel dafür.
Reverend Gonzo

Es heißt "Commit History". Geschichte wird immer in der Vergangenheitsform geschrieben. Vergangenheitsform macht also mehr Sinn. Wenn Sie auch die Commit-Historie eines Repos durchgehen, schauen Sie sich an, was damit gemacht wurde ... in der Vergangenheit!
Shiva

13

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.


1
"Was der Diff macht", aber der Diff wird durch ein Commit erstellt, das festgeschrieben wurde. Es befindet sich bereits in der Git-Historie, wurde also bereits "angewendet".
Iulian Onofrei

9

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.


7
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.


4
Sehr gute Gründe. Ich betrachte es immer so, als ob in der Nachricht "Ich bin ein Patch und ich [Nachricht]" steht. Auf diese Weise beginnen Sie immer mit einem Imperativverb.
Florida

5

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.


1
Genau. Wenn sich das Commit auf sich selbst bezieht, ist es auch wahr, wie in "Dieses Commit behebt den F00F-Fehler".
Bzlm

4

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.


1
Sicher, genau genommen ist es wahr, dass es nicht wirklich wichtig ist. Wenn Sie jedoch einen auswählen müssen, wenn Sie einen Fehler in Ihrem lokalen Baum behoben haben und die vorgenommenen Änderungen übernehmen möchten, sagen Sie "Fixed XXX" oder "Fixes XXX" oder "Fix XXX"?
Sein

1
Ich denke, es ist wichtig, wenn der Text zu kurz ist. Manchmal sehe ich Commit-Meldungen, bei denen ich mich frage, ob 1. ein Fehler gefunden oder tatsächlich behoben wurde oder 2. ob ein Fix gefunden oder tatsächlich angewendet wurde oder 3. ob ein komplexes fehlerhaftes Verhalten teilweise oder tatsächlich vollständig behoben wurde. Und manchmal beziehen sich mehrere Commits auf denselben Fehler. In "Dieses Commit behebt das Bouncy-Problem in DrawBall () und schließt Ticket 666" spielt die Zeitform keine Rolle, da der Text ausführlich ist. Aber was hat das Commit für "DrawBall () Bounces False" getan?
Bzlm

2

" 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?


1

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.


0

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.


-1

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.


-4

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.

9
Mit anderen Worten, Sie mischen alle wohl oder übel B-)
Brian Postow

Ja schon. Denn am Ende müssen die Commit-Nachrichten nicht die englischen Königinnen sein.
Tster

2
Sie sollten sowieso nicht viele verschiedene Dinge in einem Commit tun.
Florida
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.