Warum sollte ich eine Commit-Nachricht schreiben?

18

Warum sollte ich eine Commit-Nachricht schreiben? Ich will nicht und ich finde es jedes Mal dumm.

Ein GUI-Frontend, das ich benutze und das unbenannt bleibt, zwingt Sie dazu. Ich höre jedes Mal andere, die das tun, auch wenn sie das VCS in der Befehlszeile verwenden.

Wenn ich mehrmals am Tag einen Commit durchführe und ein Feature noch nicht fertiggestellt habe, worüber schreibe ich dann? Ich schreibe NUR nach vielen Commits eine Nachricht und ich habe das Gefühl, es ist Zeit für einen Mini-Tag oder wenn ich einen tatsächlichen Tag mache.

Habe ich recht oder vermisse ich etwas? Ich benutze auch ein verteiltes System

user2528
quelle
1
Mach dir keine Sorgen, sag einfach "bla" in der Kommentarzeile. Solange Sie den Code niemals mit anderen teilen und solange niemand daran arbeiten wird und solange Sie den Code niemals zurücksetzen müssen und solange Sie niemals einen einzelnen Codefehler begehen und ... Moment mal, warum setzt du die Versionskontrolle wieder ein?
Michael Durrant

Antworten:

24

Um alle Leute sagen : „verpflichten nur , wenn Sie eine nützliche, dachte gut Nachricht zu schreiben, und wenn Ihre Funktion 100% abgeschlossen ist, und Sie haben Unit - Tests für sie“, sage ich: Du bist immer noch in der SVN - Mentalität .

Wenn Sie Git verwenden , würde ich das als intelligenten Workflow bezeichnen:

  1. Legen Sie so oft fest, wie Sie möchten . Schreiben Sie dort eine alte Schnellnachricht. Niemand wird es sowieso sehen.
  2. Nach 10 Commits haben Sie das Feature, an dem Sie gearbeitet haben, fertiggestellt. Schreiben Sie nun Tests und schreiben Sie diese Tests fest. Oder was auch immer Sie wollen. Wenn Sie TDD mögen, schreiben Sie zuerst Tests, es ist mir egal, auch Git.
  3. git rebase -iVom ersten 'chaotischen' Commit an haben Sie Ihren lokalen Verlauf hinzugefügt und korrigiert, indem Sie ihn gequetscht, bearbeitet, weggelassen und auf andere Weise in logische, saubere Commits mit netten Nachrichten aufgeräumt haben .
  4. Bitten Sie nach der Bereinigung jemanden, sich von Ihnen zu lösen.
  5. Spülen und wiederholen.

Beachten Sie, dass Sie in Schritt 3 die netten Commits erhalten, nach denen Sie gesucht haben, und dass Sie bei Verwendung von SVN auf das Commit verzichten müssen, bis Sie die ersten beiden Schritte ausgeführt haben. Dies wird in den meisten anderen Antworten vorgeschlagen. IOW, Sie möchten anderen nicht Ihren halbgeschriebenen, ungetesteten Code zufügen, so dass Sie sich eine Woche lang nicht festlegen, bis Ihr Feature fertig ist. Sie nutzen die Versionskontrolle nicht in vollem Umfang.

Beachten Sie auch, dass Sie zwischen Schritt 1 und 3 git pushIhre Änderungen an Ihrem eigenen privaten Repo-Spiegel auf dem Server vornehmen können , um kostenlose Backups zu erhalten, wenn die Festplatte Ihres Laptops ausfällt.

Alex Budovski
quelle
Gute Antwort, ich mag es. Ich habe ein bisschen Angst, Rebase zu benutzen. Hier ist ein Artikel darüber, wie es schief geht und wie es wiederhergestellt werden kann. Bluemangolearning.com/blog/2009/03/…
@acid, wenn Sie Ihre eigenen privaten Änderungen erneut vornehmen, sollte es keine Konflikte geben. Außerdem müssen Sie versuchen , hart alles in git zu verlieren.
Alex Budovski
4
Mein Workflow, Git Rocks
Nazgob
1
@Boris: Weil er eindeutig über Git spricht, was eindeutig NICHT Subversion ist
3
Es sollte wirklich keine bedeutende Arbeit sein, einen Satz zu schreiben, der besagt, was Sie gerade getan haben, und die Zerstörung der Geschichte mit Zurückweisung scheint widerlich. Angenommen, Sie haben im fünften dieser zehn Commits einen Fehler entdeckt, der erst eine Woche später behoben wird. Die Möglichkeit, es auf ein einzelnes kleines Commit zu beschränken, hilft Ihnen sehr.
Gort the Robot
55

Denn wenn ein armer Betreuer einen Fehler sucht und feststellt, dass er in rev hinzugefügt wurde. xyz, er wird wissen wollen, was rev. xyz sollte das tun.

Peter Taylor
quelle
38
Na dann kann er die 5.000 Zeilen Spaghetti lesen, die ich gerade eingecheckt habe, JEESH !!! Manche Leute sind einfach faul!
Edward Strange
9
Denn wenn der arme Trottel nach dir kommt (in 3 Jahren) und sich die Geschichte ansieht und geht ... WTF ... WTF ... WTF, wird er zumindest eine Vorstellung davon haben, was los war. Sie können leicht einen Kommentar wie "Routine-Check-in, Feature X, unvollständig" hinzufügen.
quick_now
3
@ acidzombie24: Weil jedes Commit sagen sollte, wofür es gedacht ist - auch wenn es "korrigierter Tippfehler in ..." ist, hat ein Revisionsverlauf keinen Sinn, es sei denn, Sie wissen, wofür die Revisionen sind.
Orbling
11
@quickly_now, der arme Trottel könnte sogar du selbst sein. Leider ist dies eines der Dinge, die Sie selbst erleben müssen , um es vollständig zu schätzen.
2
@acidzombie - warum checkst du unvollständige Änderungen ein?
Edward Strange
35

Sie kommentieren Ihren Quellcode, richtig?

Sie schreiben die allerbesten Kommentare, diejenigen, die sagen, warum, wie der Code nur sagt, wie ?

Die Festschreibungsnachricht ist ein solcher Kommentar, und daher ist sie sehr wichtig. Je mehr Sie sich Gedanken machen, umso nützlicher ist sie für einen zukünftigen Softwarewarter.

Für jede aktive Software wird dieser spezielle Kommentar in etwa angezeigt

Gitk - alle Probe

(gefunden unter http://longair.net/blog/2009/04/25/a-few-git-tips/ ). So können Sie aus der Vogelperspektive sehen, wer wann an der Software gearbeitet hat und was sie getan hat.

Beachten Sie, dass dies das ultimative Ziel für den Commit-Kommentar ist, nämlich in einer solchen Liste das " Was " für Ihr zukünftiges Ich oder Ihren Kollegen anzuzeigen, und DAS ist der Grund, warum Sie darauf achten sollten, gute Commit-Nachrichten zu schreiben.

user1249
quelle
2
@acidzombie, ich kann nur für git sprechen, aber du kannst sie in sehr kleinen Schritten vor Ort festschreiben und sie dann alle in einem einzigen Festschreiben zusammenfassen, wenn du Upstream drückst. Diese Festschreibungsnachricht kann dann beschreibend sein.
2
@acidzombie, warum verpflichten Sie sich, wenn Sie nicht genügend Änderungen vorgenommen haben, um einen Kommentar zu rechtfertigen? Bitte erkläre.
2
@Thor: Da die Versionskontrolle Ihren Code vor Verlust schützt, sollte auch halbfertig erstellter Code geschützt werden.
Ben Voigt
1
@Ben, Commits sind für die Langzeitspeicherung gedacht und sollten Arbeits- "Brocken" genau widerspiegeln. Der Schutz vor Verlust ist meiner Meinung nach rechtwinklig zur Versionskontrolle und sollte durch ein geeignetes Backup-System gehandhabt werden. Ich habe Time Machine für den Mac für diesen Zweck sehr gut geeignet gefunden - ich hoffe, dass ein ähnliches System für Windows verfügbar ist.
2
+1 Ich bin ein Fan davon, meine Quellcodeverwaltung nicht mit sinnlosen Commits zu verschmutzen. Dies erleichtert die Suche nach einem bestimmten Commit (durch nützliche Kommentare) und ich weiß, dass es beim Auschecken von Code immer funktioniert. Herkömmliche Backup-Software ist eine bessere Option, um mein lokales Repository zwischen Commits zu schützen. Dies funktioniert gut mit einem DVCS, aber Sie müssen bedenken, dass ein lokaler Check-in nicht wirklich eine Sicherung Ihres Codes ist.
Adam Lear
15

Wenn die Festschreibungsmeldung für Sie dumm erscheint, scheint es, als würden Sie falsche Festschreibungen verwenden.

Commits sollten aus gutem Grund erfolgen - sie sollten sich auf Aufgaben beziehen, die Sie für die Funktion, an der Sie arbeiten, aufgeschlüsselt haben. Unabhängig davon, ob diese Aufgaben formal sind oder nur in Ihrem Kopf, sollte jede Änderung, die Sie vornehmen, eine Aufgabe mehr oder weniger abschließen und daher in irgendeiner Weise funktionsfähig sein.

Dann erfüllen Ihre Commit-Nachrichten einen viel besseren Zweck. Beschreiben Sie die Aufgabe, die Sie erledigt haben, und wenn sie nicht an einer anderen Stelle verfolgt wurde, warum diese Aufgabe benötigt wurde oder welchen Zweck sie erfüllt:

  • Die Benutzerklasse wurde für eine bessere Kapselung überarbeitet
  • API-Stubs wurden erstellt, damit Schnittstellen in der Controller-Klasse verwendet werden können
  • Die Datenbankklasse wurde in eine abstrakte Klasse konvertiert, sodass in Testfällen eine Scheindatenbank verwendet werden kann

Dann können Sie oder andere Entwickler das Repository oder den Dateiversionsverlauf durchsuchen und ziemlich einfach feststellen, wo und warum bestimmte Entwicklungen stattgefunden haben. Wenn sich herausstellt, dass eine bestimmte Revision eines Fehlers schuldig ist, gibt die Festschreibungsmeldung einen Hinweis darauf, warum diese Zeile eingefügt wurde, damit Sie sie nicht einfach herausreißen und möglicherweise etwas neu brechen, das für möglich gehalten wurde behoben, und Sie können es stattdessen auf die richtige Weise beheben.

NickC
quelle
1
+1, hört sich an, als ob er zu häufig oder an schlechten Haltepunkten festsetzt. Wenn er nur einen guten Backup-Punkt für einige experimentelle Änderungen haben möchte, kann er den Index verwenden, einen temporären Zweig, vorherige Commits ändern, anstatt neue zu erstellen, oder sogar den Rückgängig-Puffer in seinem Editor verwenden.
Karl Bielefeldt
1
@ Karl: IIRC Linus sagte in seinem Google Talk, dass durchschnittlich 6 Commits pro Tag gemacht werden. Jetzt weiß ich nicht, wie viel zu viel in Betracht gezogen wird, aber in diesem Projekt habe ich mich verpflichtet, als ich einige Überlegungen anstellte (ich schleife die richtigen Daten, ich mache nichts damit), nachdem ich die Schnittstelle generiert habe, aber bevor die Serialisierung funktioniert. und ich arbeite jetzt daran, die Serialisierung zum Laufen zu bringen, obwohl ich die Schnittstelle vor 2 Stunden hatte. Ich werde festschreiben und "Reflection Basics" sagen, sobald dies funktioniert, aber bei den ersten drei werde ich einen Kommentar hinterlassen, wenn ich leicht sehen kann, wann ein Feature bei jedem x-Festschreiben "funktioniert".
Eigentlich kann ich warten, bis ich einige grundlegende Tests in bekommen, weil sonst, wenn ich jeden Commit kommentiere, wie würde ich wissen, welche davon eine stabile Reflexion hat? 'Reflection Basics', 'Reflection Serializing', 'Reflection Serialize Test' Vorausgesetzt, Serializing ist ein Muss, könnte es das 2. oder 3. sein. Test kann Unit-Test oder Test bedeuten, zu testen, ob es an den Grundklassen arbeitet, die ich benötige. Ich denke nur, dass das Kommentieren Sinn macht, wenn ich sagen kann, dass die Grundlagen der Reflexion funktionieren, anstatt zu raten, welche der Grundlagen tatsächlich funktionieren. Es ist auch einfacher zu überfliegen / zu finden, wenn weniger zu lesen ist.
@acid, der gesamte Zweck eines Commits besteht darin, darauf zurückgreifen zu können oder Änderungen damit zu vergleichen. Wenn Sie dies jemals mit Ihren früheren Commits tun müssen, woher wissen Sie, welche Sie wählen müssen? Sie müssen hier keine Romane schreiben. "Interface Working", "Serialization Working" und "Reflection Working" sind meiner Meinung nach in Ordnung. Es gibt keine feste maximale Anzahl von Festschreibungen pro Tag. Wenn Ihre Nachrichten jedoch wie folgt lauten würden: "Einige Arbeiten an der Benutzeroberfläche" "Weitere Arbeiten an der Benutzeroberfläche" "Fast erledigt", werden Sie zu oft festgeschrieben und sollten nur verwenden Der Index.
Karl Bielefeldt
@ Karl: Was ist der Index übrigens? Ich weiß, dass GIT ein Versteck hat, aber ich glaube nicht, dass Sie darüber reden. Was tut es?
12

Commit-Kommentare lösen nicht alles. Es besteht immer die Möglichkeit, dass sie so viel irreführen , wie sie helfen - vor allem, wenn Entwickler wütend sind, sie eingeben zu müssen. Versuchen Sie Folgendes: Betrachten Sie sie als eine Brotkrümelspur im Wald oder als einen Wegpunkt zum Bergsteigen oder als Markierungskugeln. Richtig gemacht, können sie einen ansonsten verwirrenden Weg skizzieren.

Machen Sie keine große Sache aus ihnen. Sei ehrlich:

  • "Geänderte räumliche Indexelemente, Daos und Benutzeroberflächen zur Behandlung von Feature X"
  • "Inkrementelles Einchecken für Feature-Anfrage Nr. 1234 und Fehler Nr. 5678"
  • "Ich habe den letzten Build abgebrochen. Dies sind die Dateien, die ich verpasst habe."

Halten Sie es kurz und "Big Picture". Wenn möglich, beziehen Sie sich auf eine Problemnummer in Ihrem Feature / Bug-System. Einige Versionskontroll-Benutzeroberflächen enthalten ein Feld für diese Art von Dingen.

Scant Roger
quelle
2
+1 für die Idee, es kurz zu halten. Kurz und einfach und gut genug ist völlig in Ordnung.
quick_now
1
IMHO wäre eine noch bessere Anleitung das übliche "so kurz wie möglich, so lang wie nötig" Rezept; da es manchmal einfach nicht möglich ist, es kurz zu halten, ohne wesentliche informationen zu opfern
hvr
11

Es reduziert die Anzahl der WTF / Minute;)

Bildbeschreibung hier eingeben

Dies führt zu einem glücklicheren Team (das Sie nicht hasst) und einer besseren Teamleistung, möglicherweise zu geringeren Kosten

Rook
quelle
4
Ich würde darüber abstimmen, wenn Sie erläutern würden, warum dies wahr ist.
SingleNegationElimination
@TokenMacGuy - Entschuldigung, ich verfolge nicht.
Rook
1
Wie Expressive Commit-Nachrichten Reduzieren Sie WTFs / Minute (sie sicherlich)
SingleNegationElimination
@TokenMacGuy - Ich dachte, das wäre offensichtlich.
Rook
9

Der Rest Ihres Teams weiß also, dass WTF Änderungen am Projektbaum eincheckt.

Edward Strange
quelle
7
Ich füge Commit-Nachrichten für meine Projekte hinzu, wenn ich der EINZIGE ENTWICKLER bin! Denn wenn ich in 2 Jahren zurückkomme, um mir dieses Zeug anzuschauen, möchte ich wissen, was WTF ich damals gemacht habe. Ich weiß genau, dass dies in 99% der Fälle nicht berücksichtigt wird. 1% der Zeit spart mir 2 Wochen Qual, und ich denke, der Preis für die Eingabe einer 10-Sekunden-Commit-Nachricht ist den langfristigen Nutzen wert, den ich erhalten werde.
quick_now
@quickly_now, sogar Qual ? Ist dein Code so schlecht?
1
@quickly_now: Amen dazu. Innerhalb von ein oder zwei Jahren kommt eine Menge Code aus mir heraus, was jeder letzte Teil Monate später tun sollte, weiß Gott nur. Gott und meine Revisionsgeschichte.
Orbling
Oh ja. Ich stimme auch zu. Ich betrachte es als Erfahrung == Demut.
Michael Durrant
8

denn wenn Sie nicht üben, anständige Commit-Nachrichten einzugeben, werden Sie wie mein Kollege enden, der Nachrichten wie eingibt

no changes

oder

testing

für Commits mit über hundert geänderten Dateien (kein Scherz hier !!).

Wenn Sie solch ein Entwickler werden, werden Sie in den Augen des Rests der Welt dumm aussehen, egal wie dumm Sie es finden, einfach eine Nachricht einzugeben.

stijn
quelle
1
klingt wie ein perfekter Kandidat für die Begutachtung vor dem Festschreiben, wenn ich jemals einen gehört habe.
2
Oh man, ich habe mit solchen Leuten gearbeitet. Macht mich verrückt.
Sevenseacat
4

Warum verpflichten Sie sich, wenn die Änderungen nicht aussagekräftig sind?

Übernehmen Sie einfach Änderungen, die eine Bedeutung haben. ZB habe ich in der letzten Woche ein ziemlich umfangreiches Refactoring durchgeführt, was mich ungefähr 3 Tage gekostet hat. In dieser Zeit hätte ich jede Menge Verpflichtungen. Einige waren eher geringfügige Änderungen ("Klasse X in Y umbenannt, um neue Verantwortung widerzuspiegeln" oder "Methode Z verschoben () in Klasse Q"), andere waren sehr umfangreich. Wenn ich mit einem Feature / Refactoring fertig bin, überprüfe ich, ob einige Commits gequetscht werden konnten (zumindest unterstützt git das, weiß nichts über andere Tools), aber normalerweise lasse ich sie so, wie sie sind, weil es später hilft.

Ich vermute, Sie würden sich nicht mitten in der Bearbeitung einer Zeile festlegen, daher sollte dies eine Bedeutung haben. Beschreiben Sie einfach, was Sie seit dem letzten Commit getan haben.

EricSchaefer
quelle
3

Stellen Sie sich eine Situation vor, in der Sie Ihr System durch eine Änderung kaputt gemacht haben, und stellen Sie dies nach mehreren Team-Commits fest. Sie erinnern sich nicht an die Änderung, aber Sie erinnern sich, dass beim Verbessern von Feature X oder beim Entfernen einer Datei aus Modul Y etwas schief gehen könnte.

Die Versionsnummer gibt jedoch leider keinen Aufschluss darüber, wann Sie X oder Y geändert haben. Sie können also entweder alle Codes lesen, die in den letzten N Tagen festgeschrieben wurden, oder nur detaillierte Festschreibungsmeldungen lesen, die Sie geschrieben haben (viel besser lesbar als Code).

Wenn Sie also den gleichen, langweiligen, nutzlosen, nicht verwandten Text in eine Festschreibungsnachricht schreiben, ist dies schädlicher, als wenn Sie eine Festschreibungsnachricht haben. Denn anstatt die Wurzel des Fehlers zu finden, werden Sie durch eine falsche Nachricht in die Irre geführt.

Schreiben Sie also bei jedem Commit sinnvolle Commit-Nachrichten, die Ihnen und dem Maintainer ebenfalls helfen können.

GG01
quelle
Warum sollte ich das bei jedem Commit tun, anstatt am Ende des Tages, an jedem zweiten Tag oder wenn ich ein Feature beende?
1
Warum begehen Sie das oft, wenn es keinen "natürlichen" Grund gibt?
Ich verpflichte mich, wann immer ich wesentliche Änderungen vornehme, damit dies im Repository widergespiegelt wird und andere Entwickler diese Änderungen überprüfen können. Aber die Antwort, die Sie gaben, hilft, einen Überblick darüber zu haben, was von wem und wann getan wird.
GG01,
@ acidzombie24 Nun, begebe keine halbfertigen Sachen, es sei denn, du musst es wirklich. Und so können die anderen Leute sehen, was Sie tun / arbeiten, wenn Sie eines Tages krank anrufen und nichts funktioniert. Zumindest können Sie sich daran erinnern, wo Sie aufgehört haben, als Sie zwei Tage lang in Besprechungen sitzen mussten. Zumindest können Sie leichter feststellen, welche Revision einen Build beschädigt hat, und sich das Differential ansehen.
Nr.
@ Thorbjørn: Warum sollte ich keine Änderung vornehmen, die ich nicht wiederholen möchte?
3

Wenn Sie mit anderen zusammenarbeiten, ist es sehr wichtig, dass Sie Nachrichten festschreiben, um tatsächlich zu sehen, was andere getan haben: Das Nachschlagen der Unterschiede für jeden von ihnen ist viel arbeitsintensiver, und Sie können möglicherweise nicht nachvollziehen, warum jemand dies getan hat. Wenn Sie mit anderen zusammenarbeiten und jemand (vielleicht nicht Sie) zurückblicken muss, um beispielsweise zu verfolgen, wie sich das Verhalten gegenüber der vorherigen Version auf unerwartete Weise geändert hat, machen Sie sich das Leben wirklich schwer, indem Sie keinen hilfreichen Hinweis im Commit verwenden Botschaft.

Wenn Sie alleine arbeiten ... an einem Projekt, das größtenteils "so wie es ist" codiert ist (zum Beispiel eine einzelne einfache Website oder ein Skript), kann ich mehr oder weniger sehen, woher Sie kommen. Wenn ich an so etwas arbeite, kümmert es mich nur um das Datum / die Uhrzeit oder die letzten Änderungen, wenn ich an etwas weiterarbeite (Sie müssen einen Punkt wiederherstellen, aber das ist nur während der Entwicklung von Bedeutung, nicht nachdem Sie es implementiert haben). Die Versionskontrolle ist nur ein Weg, um Backups mit ein paar Pluspunkten zu erstellen - ich stimme voll und ganz zu, dass das System nicht vollständig genutzt wird -, aber bei einigen kleinen Projekten ist dies möglicherweise nicht erforderlich.

Der Gedanke ist mir gekommen, bevor die Versionskontrolle auf zwei unterschiedliche Arten verwendet wurde: als Dokumentation von Änderungen im Projekt und als Hilfestellung für die vorhandenen Entwickler ... und diese beiden unterscheiden sich grundlegend voneinander. Commit-Nachrichten sind in der einen Hinsicht sehr wichtig und in der anderen Hinsicht möglicherweise meistens unbrauchbar.

Inca
quelle
3

Du verpasst was. Es muss einen Grund für die Ausführung eines Commits geben, sonst würden Sie es nicht tun.

Alles, was Sie im Kommentar tun müssen, ist, den Grund in Worte zu fassen, auch wenn es nur so ist wip: adding new state objects

Richard Harrison
quelle
genau. Auch wenn es sich (wie bereits erwähnt) nur um Code handelt, den Sie nicht wiederholen möchten, bedeutet dies offensichtlich etwas, weshalb es nicht schwierig sein sollte, eine superschnelle Zusammenfassung davon zu schreiben.
Sevenseacat
2

Wie viele andere auch, programmiere ich in meiner Freizeit ein bisschen und verwende ein Revisionskontrollsystem, um meine Entwicklung und Änderungen zu verfolgen. Die Menge an Freizeit, die ich zur Verfügung habe, variiert stark von Woche zu Woche und von Monat zu Monat. In vielen Fällen hatte ich wochen- oder sogar monatelang keine Zeit, Code für ein Projekt zu schreiben, und die Zeitspanne, die ich bisher hatte, lag normalerweise zwischen 10 Minuten (typischer Tag) und 40 Minuten (guter Tag). Das sind sicher keine guten Voraussetzungen - vor allem für Debugging-Probleme.

Es war wichtig, Notizen aufzubewahren, die nicht verloren gingen und leicht abzurufen waren. Am Ende jeder Sitzung wird die Arbeit der Sitzung mit einer detaillierten Meldung festgeschrieben. Ich könnte dann die Commit-Historie durchgehen und meinen Fortschritt und Gedankenprozess verfolgen. Dadurch konnte ich mit der geringsten Menge an verlorener kostbarer Zeit dort weitermachen, wo ich letzte Woche oder letzten Monat war.

Der Punkt, den ich veranschaulichen möchte, ist, dass gute Commit-Nachrichten Ihnen (und allen anderen, die hinter Ihnen her sind) dabei helfen, herauszufinden, was passiert ist, was passiert ist, wo die Dinge laufen und vor allem warum.

Sparky
quelle
2

Denken Sie eine Minute logisch darüber nach. Wenn Sie sich verpflichten, bedeutet dies, dass etwas getan wurde. Wenn Sie keine Nachricht hinterlassen, wie werden andere wissen, was getan wurde?

Sergio
quelle
Ein Blick auf meinen unglaublich offensichtlichen Code und sie werden sofort alles wissen, was er tut und all die erstaunlichen Tests, die er zu 100% besteht. Sorry, ich bin in einer Stimmung Stimmung heute Abend [so ich scherze];)
Michael Durrant
1

Wenn Sie Ihre Commits nicht kommentieren, könnten Sie versucht sein, die Änderung in der Quelle zu kommentieren. Mit der Zeit kann dies die Quelle überladen.

Joris Geer
quelle
2
Ich bin nicht versucht, das zu tun
1

Commit-Nachrichten sind ein schneller Weg, um zu erfahren, was in diesem Check-in vor sich geht, und helfen anderen Entwicklern in Ihrem Team, wenn sie wissen möchten, welcher Aspekt des Codes in welchen Revisionen geändert wurde (aus möglicherweise Gründen).

In einem verwandten Hinweis würde ich vorschlagen, die Bug-Tracker-Fallnummer (ich hoffe, Sie verwenden eine) in der Commit-Nachricht anzugeben , so dass es für die Zukunft hilfreich wäre, Dinge einfach zu verfolgen.

Mahesh Velaga
quelle
1

Damit der Betreuer dieses Codes 1 Jahr später weiß, wen er für diesen schrecklichen Code aufspüren soll. :)

Talonx
quelle
blameDafür ist das Feature des VCS da.
Peter Taylor