Ein großer Checkin oder mehrere kleinere?

Gestern, als ich die neueste Version unseres internen Tools auscheckte, sah ich über 30 neue Versionen. Das hat mich neugierig gemacht, da ich dachte, dass endlich jemand diese nervigen Bugs repariert und das Feature hinzugefügt hat, auf das ich so lange gewartet habe ... und rate mal was? Nichts davon ist passiert, jemand dachte nur, es wäre nett, einige Header zu aktualisieren und eine kleine Anpassung von zwei oder drei Funktionen vorzunehmen. Alles in einem separaten Commit. Groß.Ein großer Checkin oder mehrere kleinere?

Dies führte zu einer Diskussion in unserem Team - sollte dies als in Ordnung betrachtet werden, oder sollten wir einen solchen "Missbrauch" verbieten? Wohl könnte dies wirklich in ein oder zwei Commits passen, aber 30 scheint zu viel. Wie soll das gehandhabt werden? Was ist die beste Vorgehensweise?

Quelle

2010-07-16 PeterK

Was ist "beleidigend" darüber?Sie scheinen auch die Konzepte "Versionen" und "Revisionen" zusammenzufassen, wenn sie nicht notwendig sind. – msw

Wenn jeder die Angewohnheit hat, jedes Committlog zu lesen, wird diese Übung in der Tat viel Zeit vom Team erfordern. Entweder die Gewohnheit oder die Praxis ist falsch. – Konerak

@msw: "beleidigend" war, dass jedes Commit die gleiche Nachricht hatte. Vergessen, das zu erwähnen. Aber Sie haben recht, dass Versionskontrollsysteme dazu entwickelt wurden, Versionen zu verfolgen, daher dürfte die Anzahl der Commits für uns nicht so wichtig sein. – PeterK

Sie sollten sich jedes Mal verpflichten, wenn Sie eine Änderung vornehmen und sind dabei, mit der nächsten fortzufahren.

Sie sollten nichts festlegen, das das Projekt am Aufbau hindert.

Sie sollten die Commit-Nachricht ausfüllen, damit die Leute wissen, welche Änderungen vorgenommen wurden.

das für mich tun würde .. Ich nehme nicht an etwas getan wurde, wenn ich es in der Commit-Nachricht sehen ...

Quelle

2010-07-16 07:48:22 Tablet

Beginnen Gebote nicht traditionell mit "Du sollst ..."? * SCNR * +1 – sum1stolemyname

@ sum1stolemyname: Lesen Sie nie einen RFC? – Konerak

@Konerak: Sollen RFCs nicht traditionell mit ["You SOLL" ... (http://tools.ietf.org/html/rfc2119) beginnen? : p – kennytm

Ich würde über die Zahl der Commits, da jeder nicht kümmern begehen hält Projektkonsistenz (Build wird weiterhin erfolgreich sein). Dies ist eine interne Zählung, die Sie nicht stören sollte. Wenn Sie etwas ändern möchten, sagen Sie den Leuten, dass sie einige strukturierte Commit-Nachrichten verwenden sollen (wie "[bugfix] ...", "[feature] ...", "[minorfix]").

Übrigens, wenn Sie wissen möchten, ob Fehler behoben wurden oder Funktionen hinzugefügt wurden, ist die Verwendung eines Fehlerverfolgungssystems viel besser als das Überprüfen von Commits in einem SVN-ähnlichen Tool.

Quelle

2010-07-16 07:51:17 schnaader

Generell denke ich, ein Commit sollte sich auf eine logische Aufgabe beziehen, z.B. Fehler 103 behoben oder eine neue Druckfunktion hinzugefügt. Dies kann eine oder mehrere Dateien sein, auf diese Weise können Sie alle Änderungen sehen, die für eine bestimmte Aufgabe vorgenommen wurden. Es ist auch einfacher, die Änderung bei Bedarf rückgängig zu machen.

Wenn jede Datei einzeln geprüft wird, ist es nicht einfach, die Änderungen für ein bestimmtes Update/Task zu sehen.

Auch wenn mehrere Aufgaben in einem Commit abgeschlossen sind, ist es nicht einfach zu sehen, welche Änderungen zu welcher Aufgabe gehören.

Quelle

2010-07-16 07:55:21

+1 Genau, ich denke, dass ein Commit eine logische Änderung widerspiegeln sollte (Bugfix , Feature, Refactoring ...), beziehen sich nicht physisch auf eine Datei oder Funktion. – PeterK

Was macht die Änderung erfordert 2 Wochen Arbeit. Sicherlich sollten Sie nicht erst nach 2 Wochen einchecken, sondern jedes Mal, wenn Sie etwas haben, das nicht kaputt geht. –

@Johann Strydom: Wahr, wenn jemand eine große Veränderung macht, sollte er es in ein paar kleinere teilen. Jedenfalls denke ich immer noch, dass dies so gemacht werden kann, dass jeder aus den Commit-Nachrichten verstehen kann, was getan wird und warum. – PeterK

Der Kampf gegen Code-Entropie ist eine fortwährende Teamarbeit. Kleine Check-Ins, bei denen man nur zerbrochene Fenster auf dem Weg hält, sollten ermutigt und nicht verpönt werden. Das Quell-Repository ist das falsche Werkzeug, um Bugfixes zu verfolgen - dafür gibt es einen Bug-Tracker - die Unannehmlichkeiten beim Finden von Fixes beim Scannen des Code-Repositorys und nicht des Bug-Repositories scheinen mir völlig unerheblich.

Ich arbeite in einem moderaten Team auf einer großen Code-Basis (~ 1M LOC) mit einer riesigen Geschichte (~ 20Y). Viel Code ist ein Haufen Chaos - verfaulte Verzweigungslogik, veraltete API, Benennungskonventionen, sogar zufällige Einrückungen machen es oft zu einem Elend zu lesen. Ich begann die Angewohnheit kleinerer "Drive-by" -Lesbarkeitsverbesserungen, versuchte, den kompletten Code-Fäulnis zu bekämpfen und bemühte mich sehr, Teammitglieder dazu zu bringen, die gleiche Gewohnheit anzunehmen.

Wenn Ihre Umstände nicht radikal anders sind, würde ich versuchen, eine solche Initiative positiv zu sehen. Die Alternative (mit der ich alle gut vertraut bin) ist die angstvolle Stagnation, die jeden Code zum Faulenzen verurteilt.

Quelle

2010-07-16 09:40:49

Es geht nicht darum, Leute daran zu hindern, Dinge zu tun. Es geht nur darum zu sagen, dass es schön wäre, wenn jemand die Änderungen an den Dateien in einem Commit eincheckt, um alles zu sehen, was geändert wurde. Es konnte nur eine Zeile in einer Datei sein, mit der Überprüfung "Fixed Rechtschreibfehler im Dialogfeld", die 5 Minuten dauerte. Normalerweise sehe ich mir die Änderungen an, die bei einem Update vorgenommen wurden, um auf dem Laufenden zu bleiben, was im Code passiert. Das Anzeigen jeder Datei, die einzeln mit "Did some stuff" eingecheckt wurde, bringt keinen großen Mehrwert. –

Ein großer Checkin oder mehrere kleinere?

Antwort

Verwandte Themen