git was soll man beim Kommentar beim commit schreiben. Das was man da gerade gemacht hat, den aktuellen Stand oder was als nächstes gemacht werden soll? Für mich ist es immer praktisch zu wissen was der aktuelle Stand ist. Aber gibt es da andere Vorgehensweisen?
Zitty Z. schrieb: > Das was man da gerade gemacht hat Das. Und zwar im Imperativ. "Change Foo to Bar" nicht "Changed Foo to Bar"
Möglichst hilfreiche Kommentare für die Nachwelt natürlich: "WTF is this shit?!" "How the fuck did this ever work?!!" "Who the hell wrote that crap?" "Lulz, segfault" "Still segfault" "Segfault fixed" "Nope, segfault still here"
Einfach mal bei anderen schauen. Zum Beispiel: https://cgit.freebsd.org/src/commit/?id=3fc3fe90915f02e25b4f1d5070e8e01e465e873d
Wie immer ist die Frage bei Dokumentation: Für wen schreibst du sie und was will die Person wissen?
Zitty Z. schrieb: > aber warum? Weil es viel einfacher zu lesen ist, wenn man sich den Commit nachher anschaut. Man liest den Kommentar "change x to y" und dann sieht man das diff, in dem x nach y geändert wird. Es gibt gar keinen Grund hier überhaupt einen zeitlichen Bezug (Vergangenheit oder Zukunft) zu haben.
Zitty Z. schrieb: > aber warum? > es ist doch schon passiert xD Wenn Du nach vorne und aus Deiner eigenen Perspektive blickst, ja. Aber in einem Team zieht sich ja bspw. ein anderer Entwickler einen neuen Stand aus git. Und dann liest es sich besser. Und manchmal dreht man ja auch Versionsstände zurück und wieder vor. Auch da ist diese Schreibweise manchmal vorteilhaft. Ist ja eh schon oft genug Gehirnakrobatik... Aber wenn man die Versionierung vorwiegend für sich alleine nutzt, ist es eigentlich egal.
Zitty Z. schrieb: > Für mich ist es immer praktisch zu wissen was der aktuelle Stand ist. Da sollte offensichtlich sein, warum man das nicht macht: Es skaliert nicht. Oder was ist "der aktuelle Stand" des Linux Kernels, wenn man in einem USB-Treiber etwas ändert? Der aktuelle Stand ist die Summe aller Commits in einem zusammenhängenden Weg zu einer Wurzel.
A. S. schrieb: > was will die Person wissen? naja man will doch wissen was das für ne Datei ist, die man da hochgeladen hat. commit 2312 : foo hinzugefügt und wenn da stehen würde: "foo hinzufügen" , dann denkt man dass man das noch hinzufügen soll xD IchNicht schrieb: > Aber in einem Team zieht sich ja bspw. ein anderer Entwickler einen > neuen Stand aus git. Und dann liest es sich besser. ok das kenne ich noch nicht. Vlt. kapiert man das dann einfach.
Zitty Z. schrieb: > Aber gibt es da andere Vorgehensweisen? "minor changes" "according requirement item zyx" "see change request xyz"
Zitty Z. schrieb: > und wenn da stehen würde: "foo hinzufügen" , dann denkt man dass man das > noch hinzufügen soll xD Nein. Commit-Logs sind keine TODO-Liste. Commit-Logs beschreiben, was ein commit macht. Nicht, was er gemacht hat. Denn du weißt gar nicht, ob der Leser der Nachricht diesen Commit bereits hat (= gemacht hat) oder nicht. Es ist unnötig einen zeitlichen Bezug zu haben. Der verwirrt nur.
RuckZuckFresseDick schrieb: > "minor changes" > "according requirement item zyx" > "see change request xyz" Alles klar. Dann sogar noch lieber git commit --allow-empty -m ""
MaWin schrieb: > Es ist unnötig einen zeitlichen > Bezug zu haben. Der verwirrt nur. ah ok ich glaube jetzt verstehe ich das ein bisschen besser. Dankee
Hannes J. schrieb: > RuckZuckFresseDick schrieb: >> "according requirement item zyx" >> "see change request xyz" > > Alles klar. Dann sogar noch lieber > > git commit --allow-empty -m "" Ein Verweis auf das zugrundeliegende Änderungsdokument, oder Requiremnt ist aber alles andere als eine leere/empty Message. Wahrscheinlich haste übersehen das [xyz] als Platzhalter für einen Link zu verstehen ist. Natürlich kann man hier auch das Referenzierte in eigenen Worten wiederholen - das ist aber wie jede Redundanz verwirrend und fehlerträchtig.
RuckZuckFresseDick schrieb: > see change request xyz Schlecht und verwirrend wird das allerdings, wenn man mehr als einen solchen Commit mit dieser Message hat. Und ein riesiges Feature in einem einzigen Commit zu implementieren ist natürlich auch schlecht. Also funktioniert das Schema nur, wenn der Change Request sehr klein ist.
Ich empfehle
> I do object to GIT's "CodeOfConduct".
Beitrag #6999702 wurde von einem Moderator gelöscht.
Zitty Z. schrieb: > MaWin schrieb: >> Und zwar im Imperativ. > > aber warum? > es ist doch schon passiert xD Weil die geläufige Konvention bei git eben ist zu sagen was der Commit machen soll, wenn man ihn z. B in seinen Code merged oder cherry-picked. Und eben nicht was der Entwickler gemacht hat. Von der "klassischen" Konvention geht die Welt sicher auch nicht unter, aber das Team sollte sich halt einig sein.
Beitrag #6999708 wurde von einem Moderator gelöscht.
> Zum Beispiel: cgit.freebsd.org ...
Wow. Ich hätte Open Source Entwickler werden sollen. Bei der Software,
an der ich jetzt weiter murksen soll, stehen im Kommentar nur 2-3
verwirrende Worte. Manchmal eine Ticketnummer, über sich herausfinden
lässt, was die Kundebetreuerin in Auftrag gegeben hatte.
Wenn du als Entwickler überhaupt nachdenkst, was da drin stehen muss,
sind deine Kommentare absolut vorbildlich einwandfrei.
A. S. schrieb: > Wie immer ist die Frage bei Dokumentation: > > Für wen schreibst du sie und was will die Person wissen? Ein Fall der mir immer mal wieder begegnet: von Benutzern/Tester wurde ein Fehler gemeldet, ist als Ticket/Issue Nr.xYz eingetragen. Dessen Ausmerzung umfass Änderungen an mehreren Dateien, durchaus auch über mehrere Commits, im Abstand von mehreren Tagen.. Wie findet man später alles was dazugehört wieder? Bloss übers Datum greift zu kurz. Also: Ticket Nr.xYz im Commit-Kommentar nennen (gerne auch als deep-URL, falls das nicht automagisch geschieht) Ist analog zu "Anforderung Nr.aBc" usw.
P. S. schrieb: > Weil die geläufige Konvention bei git eben ist zu sagen was der Commit > machen soll, wenn man ihn z. B in seinen Code merged oder cherry-picked Ja ok, hört sich in Ordnung an :D Danke Leute!
Egregio Commendatore schrieb: > Wie findet man später alles was dazugehört wieder? dann sollte eher ein Branch für den Fix erzeugt werden, damit sind die Commits dazu zusammen.
> Also: Ticket Nr.xYz im Commit-Kommentar nennen
Damit lässt sich zumindest schon mal heraus finden, warum das Programm
so einen hirnverbrannten Unfug macht.
Was immer fehlt - die Dokumentation, warum die Entwickler diese Lösung
gewählt haben.
Wussten die nicht, dass es eine einfache Lösung gibt? Funktioniert diese
einfache Lösung nicht? Hatten die keine Zeit für ein sauberes Konzept?
...
MaWin schrieb: > Es ist unnötig einen zeitlichen Bezug zu haben. Das stimmt zwar nicht, aber die Grammatik ist hier zu ungenau. Wenn dieser notwendig ist, dann schreibt man zum Kommentar auch ein Datum dazu.
Wow! schrieb: >> Zum Beispiel: cgit.freebsd.org ... > > Wow. Ich hätte Open Source Entwickler werden sollen. Bei der Software, > an der ich jetzt weiter murksen soll, stehen im Kommentar nur 2-3 > verwirrende Worte. Manchmal eine Ticketnummer, über sich herausfinden > lässt, was die Kundebetreuerin in Auftrag gegeben hatte. > > Wenn du als Entwickler überhaupt nachdenkst, was da drin stehen muss, > sind deine Kommentare absolut vorbildlich einwandfrei. Ja. Im (kommerziellen) Berufsumfeld wollen zwar alle "intelligente tools", gerne mit KI gewürzt. Will aber ein Entwickler genau sowas einführen, resp. solche tools miteinander integrieren erfordert das je nach "legacy"/Alter Kruscht soundsoviele Stunden Arbeit; weil diese nicht am Produkt selbst ist, gilt sie als "unproduktiv" (kann nicht einfach auf die morgige Kundenrechnung draufgeschlagen und kassiert werden) und wird nur selten genehmigt oder braucht unverhaeltnismaessig viel Lobbyaufwand damit man sowas "darf". OpenSource-Projekte sind da viel offener und haben bessere chancen auf solche "best practices" drumherum. Schau dir alleine an wie gerade dieses FreeBSD "alt" ist, das kann man heute durchaus als Legacy bezeichnen. Damals konnten viele Firmen nichtmal "Versionierungssystem" buchstabieren, geschweige denn die Notwendigkeit dafür einsehen. Es ist mühsam die Arbeitskultur uneinsichtiger Arbeitskollegen positiv umzukrempeln. Noch mühsamer bei Arbeits"kollegen" auf höherer Hierarchiestufen denn die fordern zwar Top-Engagement , bremsen aber umsomehr bei dafür notwendigen Top-Tools/-Methoden... BTDT.
Was als Kommentar sinnvoll ist, hängt von der restlichen Umgebung ab. Wenn die Kommentare in der Versionsverwaltung die ganze Doku sind, gehört primär in lesbarer Form das rein, was trockener im zugehörigen diff dieses Commits steckt. Also grob was + warum. Wenn man es aber ernsthafter macht, wird es irgendwo ein Trackingsystem geben. Da stehen letztlich Aufgaben drin (seien es zu entwickelnde features oder zu lösende Probleme), jedes als einzelnes issue oder Ticket oder wie auch immer man es nennt mit einem kurzen Titel und einer eindeutigen Nummer. Dann ist im Kommentar zum Commit das wichtigste, den Bezug zum Trackingsystem herzustellen (falls das issue mit seiner Nummer nicht ohnehin zwangsweise beim Einchecken angegeben werden muß, wie bei uns in den wichtigen Projekten). Dann würde ich als Kommentar die Kurzbeschreibung und die Id aus dem Trackingsystem nehmen. Wenn das zu nüchtern ist und nicht viel aussagt, dann zusätzlich noch ein knapper Text. Egregio Commendatore schrieb: > Ein Fall der mir immer mal wieder begegnet: von Benutzern/Tester wurde > ein Fehler gemeldet, ist als Ticket/Issue Nr.xYz eingetragen. Dessen > Ausmerzung umfass Änderungen an mehreren Dateien, durchaus auch über > mehrere Commits, im Abstand von mehreren Tagen.. > > Wie findet man später alles was dazugehört wieder? > Bloss übers Datum greift zu kurz. > Also: Ticket Nr.xYz im Commit-Kommentar nennen (gerne auch als deep-URL, > falls das nicht automagisch geschieht) Zumindest bei uns ist es so (und wohl auch üblich), daß der eingecheckte Code immer komplett, kompilierbar und lauffähig sein muß. Ein neues Feature oder ein größerer Fix wird bis zur Fertigstellung lokal gehalten, oder "geshelved", oder in einem eigenen privaten Branch gehalten, und fließt erst zum Schluß ein für die Öffentlichkeit sichtbar, wenn er funktioniert und nichts anderes behindert. Damit ist es im Idealfall letztlich ein commit im Hauptzweig. Wenn mehrere Hundert Entwickler dauernd halbgare Sachen speichern und kleckerweise nachbessern, würde es nie einen Stand geben, der auch mal kompilierbar ist. (Das wurde in der Vergangenheit nicht so eng gesehen. Da musste dann für jeden gelieferten Zwischenstand ein kleiner Branch gemacht werden, in den nur noch Fixes einflossen, die aber auch in den Hauptzweig dupliziert werden mussten. Weil solche Zwischenlieferungen aber wöchentlich in Dutzenden Varianten vorkamen, war der Aufwand unnötig hoch. Jetzt ist immer der Hautpzweig zumindest im Groben benutzbar, und nur noch für wichtige Lieferstände wird ein Branch gezogen, in dem dann nur noch gefixt wird.) Natürlich kommt es auch mal vor, daß ein Commit nicht der Weisheit letzter Schluß ist. Dann gibt es für einen Fix halt nochmal ein Commit, dessen Kommentar sich dann klar auf den ursprünglichen bezieht und entweder wieder dessen Kennung aus dem Trackingsystem hat, oder es gibt dort schon einen neuen Eintrag für den nötigen Fix, wenn alles korrekt läuft. Aber der Regelfall ist bei uns: eine komplette Änderung = ein Commit.
:
Bearbeitet durch User
Klaus W. schrieb: > Aber der Regelfall ist bei uns: eine komplette Änderung = ein Commit. Aber eine Änderung ist erst dann komplett wenn die Testabteilung ihren Segen gegegeben hat. Und die Testabteilung nimmt ihre zu testenden Images nicht über den kurzen Dienstweg (email-anhang) sondern auch aus dem Git. Somit hat man zwangsläufig den Fall das man ungetestet und damit unfertige Versionen comitten muß. Somit kann 'das Paradies: eine Änderung, ein Commit' nie auftreten.
Jörg W. schrieb: > Einfach mal bei anderen schauen. Zum Beispiel: > > https://cgit.freebsd.org/src/commit/?id=3fc3fe90915f02e25b4f1d5070e8e01e465e873d ...und die History von Projekten durchschauen und dich selbst fragen, welche der Commit-Messages dir sinnvolle Infos geben und welche nicht. MfG, Arno
RuckZuckFresseDick schrieb: > Aber eine Änderung ist erst dann komplett wenn die Testabteilung ihren > Segen gegegeben hat. Es ist bei uns in der Tat noch etwas komplizierter: Nachdem der Entwickler seine Änderungen fertig hat, geht es erstmal in ein Review. Dabei ist es noch nicht in den Hauptzweig eingecheckt. Erst nach dieser Freigabe wird ein automatisches Commit ausgelöst, das dann aber auch noch nicht sichtbar wird. Es wird im Verborgenen ein eigener Branch angelegt, in dem diese Änderungen in den aktuellen Hauptzweig (bzw. letztlich eine Kopie davon) gemerged werden. Dieser Zweig wird in allen nötigen Varianten gebaut, codechecker angeworfen und ggf. automatisierte Tests darauf losgelassen. Je nach Ergebnis geht es dann zurück an den Entwickler, oder es wird tatsächlich (automatisch) eingecheckt; erst dann ist es für die anderen als Änderung sichtbar. Manuelle Tests und in den Fahrzeugen kommen dann aber erst danach, insofern gibt es noch die Chance nachbessern zu müssen. Für sowas gibt es von allen Varianten zumindest wöchentliche Teststände, die als Gesamtsystem getestet werden. Endgültige Lieferungen gehen wie gesagt in Branches, die dann intensiver getestet werden, aber dafür keine Alltagsänderungen mehr bekommen.
Wow! schrieb: >> Zum Beispiel: cgit.freebsd.org ... > > Wow. Ich hätte Open Source Entwickler werden sollen. :-) Sind halt Leute, die das "for fun" machen. Gibt auch 'ne Policy. Kann sich der TE ja mal ansehen für Anregungen: https://freebsdfoundation.org/wp-content/uploads/2020/11/Writing-Commit-Messages.pdf Ich glaube, es gab schon mal eine seitenlange commit message für eine einzige geänderte Codezeile – weil eben die Änderung als solche keineswegs so offensichtlich war.
Netzwerker schrieb: > Ich schreibe immer 'Bugfix' Das klingt aber überheblich, ich bleib da bescheiden: 'try to fix' oder 'fix one, create two' ;-)
Jörg W. schrieb: > Ich glaube, es gab schon mal eine seitenlange commit message für eine > einzige geänderte Codezeile – weil eben die Änderung als solche > keineswegs so offensichtlich war. Das nennt man Missbrauch der commit-Funktion weil zu faul dedizierte Fall-Doku zu schreiben und dem Commit als Datei mitzugeben. Mindestens hätte man der Codezeile ein par Comment-zeilen zur Seite stellen sollen, damit derjenige, der nur den Code aber nicht die CommitPsalmodirerei zum Review vorliegen hat, auch seine Chance auf Verständnis bekommt ...
RuckZuckFresseDick schrieb: > Das nennt man Missbrauch der commit-Funktion Klar, weil du dich so genau auskennst, was da genau passiert ist und wie der Code tatsächlich aussieht, kannst du das auch beurteilen.
Jörg W. schrieb: > RuckZuckFresseDick schrieb: >> Das nennt man Missbrauch der commit-Funktion > > Klar, weil du dich so genau auskennst, was da genau passiert ist und wie > der Code tatsächlich aussieht, kannst du das auch beurteilen. Ich kann sehr wohl beurteilen, das die Anzahl der Leser des Commit-Kommentars sehr viel kleiner ist als die Anzahl derer die den Inhalt des besagten Kommentars nötig hätten. Ich mein, es ist richtig Doku und Erläuterung zu schreiben und es ist falsch diese Doku in den Papierkorb zu werfen. Und die commit-mesage ist nun mal das was einem Papierkorb am nächsten kommt, weil sie von den wenigsten Beteiligten gelesen wird. Oder gelesen werden kann... denn in einem source tar ball ist der commit-kommentare meist nicht enthalten.
RuckZuckFresseDick schrieb: > Ich kann sehr wohl beurteilen, Nein, diese Fähigkeit spreche ich dir ab, da du absolut keine Ahnung hast, was an dieser Stelle tatsächlich passiert ist und wie das im Sourcecode dokumentiert ist. Du darfst aber dessen gewiss sein, dass FreeBSD ein in vielerlei Hinsicht sehr pingelig arbeitendes Projekt ist. Undokumentierten Code bekommst du da nicht durch. (Ich kann mich leider auch an zu wenige Details erinnern, um das jetzt nach so vielen Jahren wieder ausgraben zu können.)
Vincent H. schrieb: > Möglichst hilfreiche Kommentare für die Nachwelt natürlich: > > "WTF is this shit?!" > "How the fuck did this ever work?!!" > "Who the hell wrote that crap?" > "Lulz, segfault" > "Still segfault" > "Segfault fixed" > "Nope, segfault still here" LOL
Jörg W. schrieb: > RuckZuckFresseDick schrieb: >> Ich kann sehr wohl beurteilen, > > Nein, diese Fähigkeit spreche ich dir ab, da du absolut keine Ahnung > hast, was an dieser Stelle tatsächlich passiert ist und wie das im > Sourcecode dokumentiert ist. Ich kann natürlich nursoviel Ahnung haben wie dein zitierter beitrag zuläßt. Und da steht viele commitzeile für eine einzige Code-zeile. Aber egal um wieviele LoC es geht, der Commitkommentar ist der falsche Ort für die Code-Doku - auch wenn das ein selbstgefälliger Moderator das kindischwerweise anders sieht.
RuckZuckFresseDick schrieb: > ist der falsche Ort für die Code-Doku Das ist es auch nicht, und dein Irrtum wird nicht besser, wenn du jetzt anfängst, in die Schimpfwortkiste zu greifen.
Jörg W. schrieb: > Das ist es auch nicht, und dein Irrtum wird nicht besser, wenn du jetzt > anfängst, in die Schimpfwortkiste zu greifen. Du kannst auch gleich noch mit dem Fuß aufstampfen, denn Dein Verhalten ist kein Deut besser. Aber egal, mein Posting wird eh gleich von Dir gelöscht.
Einer schrieb: > Du kannst auch gleich noch mit dem Fuß aufstampfen Ist nicht notwendig, denn Jörg hat recht.
MaWin schrieb: > Ist nicht notwendig, denn Jörg hat recht. Ich bin mir nicht sicher, auch ich kenne den Code nicht. Aber ich hätte vermutlich den langen Text (commit Kommentar) in den Quelltext zur Änderung geschrieben und im commit Kommentar darauf deutlich hingewiesen. Ich fürchte auch, ein zu langer commit Kommentar wird nicht gelesen. Aber am wichtigsten ist erstmal, dass es überhaupt einen sinnvollen und hilfreichen Kommentar gibt. Das ist längst nicht immer gegeben.
:
Bearbeitet durch User
900ss D. schrieb: > Aber ich hätte > vermutlich den langen Text (commit Kommentar) in den Quelltext zur > Änderung geschrieben und im commit Kommentar darauf deutlich > hingewiesen. Also erstens ist das keine lange Commitmessage. Im OpenSource-Umfeld sind die Commitmessages in der Regel deutlich länger. Zweitens beschreibt die Commitmessage im Beispiel - so wie es auch sein soll - zu 90% die Änderung, und nicht den geänderten Code. Das ist ein Unterschied. Und das ist genau, wie es gedacht ist. Es wird nicht beschrieben, was der Code macht, sondern warum er geändert wird. Und drittens fügt die Änderung einen Kommentar hinzu, der den Code genauer beschreibt. Es bleibt keine Codebeschreibung in der Commitmessage übrig, die nicht auch im Code beschrieben wäre.
Jörg W. schrieb: > RuckZuckFresseDick schrieb: >> ist der falsche Ort für die Code-Doku > > Das ist es auch nicht, und dein Irrtum wird nicht besser, wenn du jetzt > anfängst, in die Schimpfwortkiste zu greifen. Oh, da entschuldige ich mich gleich, falls 'Moderator', 'selbstgefällig' und/oder 'kindisch' als Schimpfworte angesehen werden. Das ist keinesfalls als Beschimpfung gedacht, höchstens als eindringlich vorgetragenen Aufforderung nochmals das bisher Gesagte zu überdenken. Ich seh da wirklich Diskussionsbedarf hinichtlich der Frage, ob ein commit-Kommentar wirklich der richtige Platz für eine Dokumentierenden Textpassage ist. Insbesonders unter dem Aspekt der 'Sichtbarkeit', eben das Commit-Kommentare nicht Bestandteil des Softwarepaketes sind, die dann verteilt werden. Nur der Depot-Verwalter sieht/braucht diesen Commit. Wenn man genötigt wird, Commit-Kommentare durchzusehen um die Funktionalität des Codes nachzuvollziehen, dann erinnerst das an den Hitchhiker Guide to the Galaxy" bei der sich ein Protagonist auch darüber beschwert, das Die Abrisspläne für sein Grundstück in einen finsteren schwer zugänglichen Keller 'ausgehangen waren'. Ein commit Kommentar ist lediglich ein kurzer Hinweis was darin geändert wurde, aber keine Rechtfertigung desselben. Dehalb genügt ein Verweis auf den Änderungs- resp. Featurerequest/Spec..
MaWin schrieb: > Also erstens ist das keine lange Commitmessage. Jörg W. schrieb: > Ich glaube, es gab schon mal eine seitenlange commit message für eine > einzige geänderte Codezeile Ok, was eine lange commit Message ist, das ist relativ :) Seitenlang ist für mich lang.
RuckZuckFresseDick schrieb: > ob ein > commit-Kommentar wirklich der richtige Platz für eine Dokumentierenden > Textpassage ist. Was verstehst du unter "Dokumentierenden Textpassage"? Wenn die Textpassage die Änderung dokumentiert, dann ist die Commitmessage genau der richtige Platz dafür. Wenn die Textpassage den Code dokumentiert, dann ist die Commitmessage eventuell auch der richtige Platz dafür, wenn diese Textpassage zusätzlich zum Beispiel auch noch sinngemäß in der Doku oder im Kommentar auftaucht. > Wenn man genötigt wird, Commit-Kommentare durchzusehen um die > Funktionalität des Codes nachzuvollziehen Niemand wird das. > Ein commit Kommentar ist lediglich ein kurzer Hinweis was darin geändert > wurde, aber keine Rechtfertigung desselben. Eben doch. Die Rechtfertigung der Änderung ist der Hauptteil einer guten Commitmessage.
900ss D. schrieb: > Seitenlang ist für mich lang. Es ging um das gezeigte Beispiel, nicht? Die ist nicht seitenlang, sondern nur ein paar kurze Sätze.
RuckZuckFresseDick schrieb: > falls 'Moderator', 'selbstgefällig' und/oder 'kindisch' als Schimpfworte > angesehen werden. Nun zumindest sind das **unnötige** persönliche bewertende Ausdrücke und entbehren der Sachlichkeit.
:
Bearbeitet durch User
MaWin schrieb: > Es ging um das gezeigte Beispiel, nicht? Ich hatte es so verstanden, als wenn es um die erwähnte seitenlange commit Message ging. Vielleicht lag ich falsch.
:
Bearbeitet durch User
900ss D. schrieb: > Ich hatte es so verstanden, als wenn es um die seitenlange commit > Message ging. Wie dem auch sei. Eine seitenlange Commitmessage kann völlig in Ordnung sein, wenn sie die Änderung (nicht den Code) beschreibt. Falls sie den Code beschreibt, sollte diese Beschreibung selbstverständlich auch noch irgendwo anders existieren.
MaWin schrieb: >> Wenn man genötigt wird, Commit-Kommentare durchzusehen um die >> Funktionalität des Codes nachzuvollziehen > > Niemand wird das. Doch, solange eben der Inhalt der commitmessage nicht irgendwo anders auftaucht. Deshalb die oben beschrieben Vorgehensweise, die seitenlange Begründung nicht in die commit-message zu packen sondern in die Doku die in dem comitteten Pakt beigefügt ist ... aber vielleicht liegt ja genau hier der Denkfehler, zu glauben das nur source comittet wird und nicht gleichzeitig die Doku (ins doc-directory oder als source commentar. dann hätte auch doxygen eine Chance diese zu finden ... als commit-message wäre das auch für doxygen verloren. >> Ein commit Kommentar ist lediglich ein kurzer Hinweis was darin geändert >> wurde, aber keine Rechtfertigung desselben. > > Eben doch. Die Rechtfertigung der Änderung ist der Hauptteil einer guten > Commitmessage. nein die commitmessage ist lediglich der verweis auf den Request der zu der Änderung geführt hat. Kein Start von Änderungsarbeiten ohne (triftigen) Anlaß- 'Rechtfertigung' klingt doch stark nach - ich hatte mal Langeweile und hab am Code rumgekritzelt und mir nachträglich ne Begründung einfallen lassen ...
MaWin O. schrieb: > Wie dem auch sei. Eine seitenlange Commitmessage kann völlig in Ordnung > sein, wenn sie die Änderung (nicht den Code) beschreibt. > Falls sie den Code beschreibt, sollte diese Beschreibung > selbstverständlich auch noch irgendwo anders existieren. Wieso diese doppelte Existenz? Die Änderung wir einmal beschrieben und diese Beschreibung wird als file oder eben fileänderung dem Commit beigefügt. Damit Fertig und nachvollziehbar bis in alle Ewigkeit.
RuckZuckFresseDick schrieb: > nein die commitmessage ist lediglich der verweis auf den Request der zu > der Änderung geführt hat. Das ist genau die Kritik. Das kommerzielle Umfeld sieht das in der Regel so wie du. Das OpenSource-Umfeld sieht das so wie wir. OpenSource hat Recht.
Lieber ein langer sinnvoller Kommentar beim Commit als ein endloses Herumgehacke von gelangweilten Rechthabern...
RuckZuckFresseDick schrieb: > nein die commitmessage ist lediglich der verweis auf den Request der zu > der Änderung geführt hat. Im Opensource-Umfeld gibt es nicht für jedes und alles ein Ticket. Da können Fehler schon auch mal in eigenen Stresstests auftauchen oder in Mails oder Chats zwischen den Entwicklern geäußert werden. Dann ist die Commitmessage sehr wohl ein Platz dafür zu dokumentieren, dass damit beispielsweise ein vormaliges Fehlverhalten korrigiert worden ist. Im kommerziellen Umfeld sieht das (je nach Umgebung) natürlich anders aus.
RuckZuckFresseDick schrieb: > Wieso diese doppelte Existenz? Weil es die Commitmessage selbsterklärend macht. Ein Link auf irgendein Dokument ist nicht selbsterklärend. Und ja, selbsterklärende Commitmessages sind wichtig. Insbesondere bei dezentraler Entwicklung. (Was ja heute der Standard sein sollte). Niemand hat Lust Anforderungsdokumente zu wälzen, nur um zu entscheiden, ob er einen Commit mergen soll. > Damit Fertig und nachvollziehbar bis in alle Ewigkeit. Was sich ja nicht von der OpenSource-Vorgehensweise unterscheidet.
MaWin O. schrieb: > Das kommerzielle Umfeld sieht das in der Regel so wie du. > Das OpenSource-Umfeld sieht das so wie wir. > > OpenSource hat Recht. Na da denk ich mir einen smiley in das Zitat und alles ist Friede, Freude, Eierkuchen in der jeweiligen Blase ...
Klaus W. schrieb: > Lieber ein langer sinnvoller Kommentar beim Commit als ein endloses > Herumgehacke von gelangweilten Rechthabern... Irgendwie wahr :-)
:
Bearbeitet durch User
Jörg W. schrieb: > Im Opensource-Umfeld gibt es nicht für jedes und alles ein Ticket. Da > können Fehler schon auch mal in eigenen Stresstests auftauchen oder in > Mails oder Chats zwischen den Entwicklern geäußert werden. Dann ist die > Commitmessage sehr wohl ein Platz dafür zu dokumentieren, dass damit > beispielsweise ein vormaliges Fehlverhalten korrigiert worden ist. > Im kommerziellen Umfeld sieht das (je nach Umgebung) natürlich anders > aus. Hmmm... bei "uns" im kommerziellen Umfeld gibt es diese Situationen auch, dass beim Test noch andere Bugs zu Tage kommen. Ich glaube das ist eine normale Situation die sich nicht an open source festmachen lässt. Das wurde dann im selben Ticket gefixt und dieses Ticket dann um den neuen Bug ergänzt und entsprechende Beschreibung natürlich. Damit konnte dann die commit Message kurz gehalten werden. Das blöde ist, dass man diesen Bug schwierig wieder findet im Ticketsystem. Wenn es sauber sein soll müsste man ein weiteres Ticket aufmachen. Aber genauso schwierig wird das "Finden" wohl, wenn es dann in der commit Message beschrieben wird. Eine Sondersituation halt. Am wichtigsten ist halt, dass es überhaupt irgendwo festgehalten wird.
900ss D. schrieb: > Aber genauso schwierig wird das "Finden" wohl, wenn es dann in der > commit Message beschrieben wird. Warum soll das schwierig sein? Das commit, welches die fehlerhafte Codezeile ändert, hat auch gleich die Beschreibung mit dabei. Leichter auffindbar gehts kaum. Warum sollte es einfacher sein, wenn ich statt der Message einen Link auf ein externes Dokument mache?
900ss D. schrieb: > Klaus hatte oben irgendwie Recht :) Aha. Eine Diskussion ist also deiner Ansicht nach sinnlos. Gut zu wissen.
Da hat doch glatt einer seinen Account und Passwort wiedergefunden. :o)) Oder ist es der Falsche, der meinen Tipp übernommen hat? ;o))
Gastbeiträge werden hier im Forum ja mittlerweile von der Anzahl her begrenzt.
MaWin schrieb: > Gastbeiträge werden hier im Forum ja mittlerweile von der Anzahl her > begrenzt. Die Beschränkung gibt es schon etwas länger. Wenn jetzt schon Freitag wäre, würden wir jetzt die Länge der Leitung in Lichjahren ausrechnen. Zwölve in einer Stunde zu posten, geht durchaus problemlos. Ist alles nur eine Frage des Wissens, wie so was geht.
Was willst du mir mit diesem Beitrag sagen?
@TO Mich würde mal interessieren welche Antwort du aus diesem Beitragsgefecht gewonnen hast. Also, wie Du nun gedenkst commit-Messages zu verfassen (oder auch nicht). Vielleicht kannst Du dir ja mal diese Minute für ne Antwort Zeit nehmen.
hi, habe jetzt meine Schreibweise auf ein todo umgeändert: also imperativ "füge extra funktion hinzu" "update variablen-namen" keine Ahnung,ob das richtig ist. Aber es macht Spaß :D außerdem werde ich weiter schauen wie andere das so machen :)
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.