Commit-Nachrichten als Solo-Entwickler schreiben?

In meinen Projekten, in denen das Repository von mir und anderen Programmierern gemeinsam genutzt wird, schreibe ich immer Commit-Nachrichten, auch wenn ich der Hauptentwickler bin.

Aber bei Projekten, bei denen ich als Einzelentwickler an einem Projekt arbeite und das Repository auf meinem persönlichen Laptop gehostet wird und nicht einmal vom Client gehostet wird, würde niemand außer mir die Commits sehen, sollte ich noch ein Commit schreiben Mitteilungen?

Bisher habe ich sie geschrieben, aber ich habe festgestellt, dass ich nie zurückgegangen bin und meine Commit-Nachrichten angesehen habe. Ich nehme mir Zeit für die Entwicklung, um die Nachrichten aufzuschreiben, aber dann werden sie selbst von mir nie wieder gesehen.

Gibt es gute Gründe, als Einzelentwickler Commit-Nachrichten zu verfassen, oder sollten Sie diese einfach überspringen, um sich weiterhin auf die Entwicklung zu konzentrieren?

Nun, hier ist ein Grund: Wenn Sie plötzlich feststellen, dass in den letzten hundert Commits etwas kaputt gegangen ist (möglich, wenn Sie bei jeder geringfügigen Änderung einen Commit ausführen, weniger machbar, wenn Sie wie ich nur "stabile" Snapshots ausführen), können Sie dies einfacher tun Finden Sie heraus, wo Sie den Fehler eingefügt haben, wenn Sie eindeutige Commit-Nachrichten geschrieben haben, und nicht "Bugfixes". (Die Lieblingssaite eines Kollegen, glaube ich). Sicher, Sie können mit svn logoder mit welchem ​​SCM Sie arbeiten, aber anders herum sollte es einfacher sein.

Commit-Nachrichten zwingen Sie auch dazu, genau zu überlegen, was Sie als Änderung getan haben, und ich glaube, Sie können in Ihren Gedanken zusammenfassen, wie es am besten wäre, das Projekt weiter zu verbessern.

Ich versuche es immer. Wie oft blicken Sie zurück und denken: "Mann, was habe ich getan, als ich diese Änderung vorgenommen habe?" Ich mache die ganze Zeit. 30 Sekunden nach dem Schreiben einer Nachricht sparen Sie 20 Minuten Arbeit, die Sie sich merken müssen.

Glauben Sie ehrlich, dass die Eingabe von 40 bis 80 Zeichen im Klartext einen erheblichen Mehraufwand für ein Commit bedeutet, oder suchen Sie nach einer Entschuldigung, um faul zu sein?

Möglicherweise müssen Sie den Zweck der Änderung überprüfen, bis Sie sich fragen, ob Sie es wirklich tun müssen.

Mein Rat ist nicht zu glauben, dass Sie die Regeln brechen können, weil Sie alleine fliegen. Bleiben Sie jederzeit professionell und fügen Sie aussagekräftige Commit-Nachrichten hinzu. Wie von anderen Repondern bemerkt, werden Sie eines Tages dafür dankbar sein.

• Sie werden nicht immer ein Solo-Entwickler sein.

• Sie werden irgendwann Ihre Codebasis aufbrechen und versuchen, sie wiederherzustellen. Gute Commit-Nachrichten sparen Ihnen Stunden.

• Sie können sich nicht erinnern, woran Sie vor drei Wochen gearbeitet haben, oder?

• Commit-Meldungen sollten sehr klar sein. Wenn dies nicht der Fall ist, haben Sie die Arbeit an einer Aufgabe entweder noch nicht abgeschlossen oder eine einzelne Aufgabe wurde auf zwei oder mehr Aufgaben verteilt.

Auf jeden Fall, oder Sie erschweren die Verwendung von Funktionen wie Verzweigen und Zusammenführen erheblich. Und Sie werden sie auch als Solo-Entwickler verwenden wollen.

Ein möglicher Grund: Sie müssen abstrakter über die gerade vorgenommene Änderung nachdenken und Änderungen strukturieren.

Wenn es sich sinnlos anfühlt, kommentieren Sie einfach die wichtigsten Änderungen oder diejenigen, die die vorhandene Funktionalität ändern, falls Sie jemals nach der Quelle eines seltsamen Verhaltens suchen.

Ich war der einzige Verfasser des TXR-Projekts und habe von Anfang an ein detailliertes ChangeLog geführt. Dies sind fast 11.000 Zeilen, die zunehmen: http://www.kylheku.com/cgit/txr/tree/ChangeLog

(Die Commit-Nachrichten im Repo sind nur eine Kopie dessen, was im ChangeLog steht.)

[Bearbeiten von 2016: Ab Mitte 2015 verwalte ich keine ChangeLog-Datei mehr. Die Festschreibungsnachrichten werden jedoch in einem Format geschrieben, das gleichzeitig den Git- und ChangeLog-Konventionen entspricht. Der gleiche Detaillierungsgrad ist vorhanden, ohne dass Zusammenführungsprobleme auftreten. Aus diesen Kommentaren kann eine ChangeLog-Datei mechanisch rekonstruiert werden.]

Ja, ich bin mehr als einmal zu einer alten Commit-Nachricht zurückgekehrt, die mit einer Änderung in Verbindung gebracht wurde, die etwas kaputt gemacht hat (mithilfe von aufgedeckt git bisect). Die Nachricht half mir zu verstehen, was ich tat.

Im ChangeLog können Sie erkennen, wann eine Funktion, ein Typ, ein Makro oder eine globale Variable zum ersten Mal eingeführt wurde und wann sie anschließend von Änderungen berührt wurde.

Der Hauptgrund für das Schreiben von detaillierten Commit-Nachrichten wie diesen, wenn Sie alleine arbeiten, ist folgender: Sie finden dabei Fehler .

Das Schreiben einer detaillierten Festschreibungsnachricht hat ähnliche Vorteile wie eine Codeüberprüfung Ihrer Festschreibung durch eine andere Person. Der Wert in einer Commit-Überprüfung ist nicht so sehr, dass jemand Ihren Code überprüft, sondern dass Sie Ihre Änderungen einem anderen Entwickler erklären müssen.

Wenn Sie versuchen, Dinge zu erklären, stellen Sie manchmal fest, dass sie keinen Sinn ergeben.

Ein weiterer Grund: Sie können sich dabei ertappen, eine nutzlose Änderung vorzunehmen . Wenn Sie einen detaillierten Festschreibungskommentar verfassen, erhalten Sie einen umfassenden Überblick über Ihre Aktivitäten, und manchmal werden Sie mit der Tatsache konfrontiert, dass es sich nicht um eine gute Änderung handelt.

Ich habe manchmal Änderungen vorgenommen, als ich während des Schreibens des ChangeLog-Eintrags feststellte, dass dies eher ein git reset --hard( Wegwerfen dieser nutzlosen Änderungen) als ein ( Wegwerfen dieser nutzlosen Änderungen) sein würde git commit -a.

Obwohl Sie noch nicht auf die Notwendigkeit gestoßen sind, Ihre Commit-Nachrichten anzuzeigen, sind Sie möglicherweise in Zukunft sehr dankbar dafür. Du solltest sie weiterhin selbst schreiben. Es gibt viele Gründe, warum sie später nützlich sein könnten. (Sie haben vergessen, warum Sie eine Funktion hinzugefügt, fehlende Dateien gefunden haben usw.)

Hier ist eine verwandte Frage zum Zweck von Commit-Nachrichten: Warum sollte ich eine Commit-Nachricht schreiben?

Ich verpflichte mich immer mit einer aussagekräftigen Nachricht über Änderungen, und ich tue dies häufig mit inkrementellen Änderungen.

Ist das immer das Nützlichste? Nein, das ist kein Problem. Wenn Sie zu einer vorherigen Phase zurückkehren müssen, werden Sie in Ihren Nachrichten darüber informiert, wo Sie sich befinden und was Sie getan haben. Es kann auch verwendet werden, um den Fortschritt eines Projekts zu verfolgen. Was die Zeitverschwendung angeht, sind die 30 Sekunden, die benötigt werden, um einen Satz aufzuschreiben, wirklich so folgenreich?

In Bezug auf Commit-Nachrichten sehe ich keinen Unterschied, ob Sie in einem Team arbeiten oder nicht. Du erinnerst dich nur für eine begrenzte Zeit an das, was du hier oder da getan hast, und danach ist es dasselbe, als ob jemand anderes es geschrieben hätte. Sie sollten also Nachrichten so gut schreiben, wie Sie es für die anderen Leute tun würden.