Ist es in der zentralen Versionskontrolle immer gut, häufig zu aktualisieren?

Vorausgesetzt, dass:

• Ihr Team verwendet die zentrale Versionskontrolle.
• Sie arbeiten an einer größeren Funktion, deren Fertigstellung mehrere Tage in Anspruch nehmen wird, und Sie können sich vorher nicht festlegen, da dies den Build beschädigen würde.
• Ihre Teammitglieder legen jeden Tag etwas fest, das möglicherweise einige der Dateien ändert, an denen Sie arbeiten.

Da es sich um eine zentralisierte Versionskontrolle handelt, müssen Sie Ihre lokale Kaufabwicklung irgendwann aktualisieren: mindestens einmal kurz vor dem Festschreiben der neuen Funktion.

Wenn Sie nur einmal direkt vor Ihrem Commit aktualisieren, kann es aufgrund der vielen anderen Änderungen Ihrer Teamkollegen zu vielen Konflikten kommen, die eine Welt voller Schmerzen sein können, die auf einmal gelöst werden müssen.

Oder Sie können häufig aktualisieren, und selbst wenn einige Konflikte Tag für Tag gelöst werden müssen, sollte dies nach und nach einfacher sein.

Würdest du bleiben, es ist immer eine gute Idee, oft zu aktualisieren?

Persönlich aktualisiere ich meine lokalen Versionen täglich.

In dem von Ihnen beschriebenen Szenario würde ich noch einen Schritt weiter gehen

• Erstellen eines Zweigs für die neue, langwierige Funktion.
• Führen Sie häufig von der Hauptlinie zu diesem neuen Zweig zusammen.

Diesen Weg,

• Sie können täglich einchecken, um Ihren Code auf dem Server zu erhalten
• Sie müssen sich keine Sorgen machen, dass der Build beim Einchecken beschädigt wird.
• Sie können das Repository verwenden, um bei früheren Eincheckvorgängen einige Arbeiten rückgängig zu machen oder bei Bedarf zu unterscheiden.
• Sie sind sicher, dass Sie an der neuesten Codebasis arbeiten und mögliche widersprüchliche Codeänderungen frühzeitig erkennen.

Die Nachteile, wie ich sie sehe, sind

• Das Zusammenführen von main muss manuell (oder per Skript) erfolgen.
• Es braucht mehr "Administration"

Ja, es ist eine gute Idee, häufig zu aktualisieren. Sie aktualisieren häufig, um schwierige Zusammenführungskonflikte zu vermeiden. Dies sind die Grundlagen des SCM-Wissens (Software Configuration Management) mit dem Problem unterschiedlicher Änderungen.

Dies ist unabhängig davon, ob es zentralisiert oder verteilt ist. Je länger Sie von einer Upstream-Quelle abweichen (dh, wenn es sich im DVCS-Fall um eine Amtsleitung, einen Zweig oder ein anderes Repository handelt), desto höher ist die Wahrscheinlichkeit von Zusammenführungskonflikten. Ja, beim Aktualisieren können böse Überraschungen von Ihrem Team auftreten, aber das Verschieben der bösen Überraschungen ist noch schlimmer (je länger Sie warten, desto weniger Menschen erinnern sich daran, warum eine Reihe von Änderungen vorgenommen wurden).

Damit die Aktualisierung funktioniert, bedeutet dies auch, dass Sie und andere Programmierer, die an Code arbeiten, niemals wissentlich Upstream-Code festschreiben oder pushen sollten, der den Build unterbricht . Dies ist normalerweise der Grund, warum Programmierer verzweigen (oder in SCM-Begriffen vom Upstream abweichen), um Ihre Teammitglieder und andere Stakeholder vor fehlerhaftem Code zu schützen, falls eine solche Situation unvermeidlich auftreten sollte.

Das Mantra, an das Sie sich erinnern können, lautet: "Aktualisieren, Aktualisieren, Aktualisieren, Festschreiben". Stellen Sie immer sicher, dass Ihre Änderungen mit anderen funktionieren, bevor Sie sie festschreiben. Dies soll auch sicherstellen, dass das erstmalige Auschecken von Code ebenfalls funktioniert.

Der dritte Punkt in der Frage ist einfach falsch :

• Sie arbeiten an einer neuen Funktion, deren Fertigstellung sicherlich mehrere Tage dauern wird, und Sie können sich vorher nicht festlegen, da dies den Build beschädigen würde.

Wenn Sie wissen, dass Sie an etwas arbeiten werden, das Sie für einige Zeit nicht festlegen können, ist dies das Lehrbuchbeispiel für die Verwendung von Zweigen.

Versetzen Sie sich nicht in die Situation, in der viele Änderungen anstehen. Wenn Sie wissen, dass Sie einige Zeit nicht in der Hauptniederlassung Ihres Projekts festschreiben können, arbeiten Sie an einer anderen Niederlassung. Und dort oft begehen .

Wenn Sie sich bereits in der in der Frage beschriebenen Situation befinden, wechseln Sie sofort zu einem Zweig , übernehmen Sie Ihre Änderungen und arbeiten Sie in diesem Zweig weiter.

Normalerweise ist es in CVCS eine gute Idee, häufig zu aktualisieren. Wenn Sie jedoch an einem Zweig arbeiten, wird die Frage "häufig aktualisieren oder nicht" zu "häufig zusammenführen oder nicht". Und die Antwort lautet trotzdem ja. Stellen Sie einfach sicher, dass Sie alle ausstehenden Änderungen (in der Verzweigung) festschreiben, bevor Sie sie aus einer anderen Verzweigung zusammenführen, damit Sie die Zusammenführung bei Bedarf sicher zurücksetzen können.

Ich denke, Sie sollten sich öfter festlegen. Wenn Sie längere Zeit wie wenige Tage arbeiten, sollten Sie Ihren Code verzweigen und in Ihrer Niederlassung arbeiten, anstatt direkt im Trunk zu arbeiten. Ich weiß, dass es praktisch ist, ohne Verzweigungen zu arbeiten, aber es ist nicht wirklich flexibel, da Sie nicht sicher sein können, ob Ihr Update / Commit Ihren Code beschädigen würde oder nicht, was dazu führt, dass Sie Ihr Update / Commit so lange aufbewahren, bis Sie es haben habe deinen Job gemacht. "Feature-Verzweigung" ist besser, da Sie Ihren Code jederzeit festschreiben und später wieder zusammenführen können, wenn Sie fertig sind.

In der Verzweigungsstrategie wird das Update durch das Zusammenführen aus dem Trunk ersetzt. Nach meiner Erfahrung müssen Sie nicht so oft aus dem Trunk zusammenführen, da sich der Code in etwa fünf Tagen nicht wesentlich ändert und es einfacher ist, den Konflikt nur einmal zu lösen, wenn Sie fertig sind.

Ich finde es tatsächlich bequemer, eine verteilte Versionskontrolle lokal zu verwenden. Das heißt, ich benutze git als Subversion-Client. Dies hat folgende Vorteile:

• Die lokalen Änderungen werden vor dem Aktualisieren gespeichert. Wenn ich also beim Zusammenführen einen Fehler mache, kann ich jederzeit zurückgehen und es erneut tun.
• Bei größeren Änderungen kann ich die fertigen Teile speichern. Dies erleichtert die Überprüfung der verbleibenden Änderungen.
• Wenn ich während einer größeren Arbeit einen Fehler behebe, kann ich genau diesen Fix festschreiben, den Rest vorübergehend festschreiben und den Fix für die Subversion "dcommit", während die anderen laufenden Arbeiten lokal bleiben.

Wenn Sie eine neue Funktion hinzufügen, können Sie dann eine neue Einzelquelldatei (und eine passende Header-Datei für die externe Schnittstelle) erstellen?

Ich bin besorgt, dass eine "neue Funktion" weitreichende Auswirkungen hat. Objektorientierung ist vielleicht nicht mehr das Schlagwort, das es einmal war, aber dieses Paradigma hat seinen Wert.

Auf diese Weise können Sie das Framework (externe Schnittstelle plus Stub-Funktionen) erstellen und festlegen, dass dann nur minimale Effekte von Drittanbietern auftreten sollten, während Sie den Rest Ihrer Entwicklung abschließen.

In der von Ihnen beschriebenen Situation ist es meiner Meinung nach besser, mehr kleinere Quelldateien als weniger größere Dateien zu haben.

Wie unterscheidet es sich bei einer zentralisierten Versionskontrolle von einer verteilten?

In beiden Fällen müssen Sie an einem Ort einchecken, dessen Inhalt sich im Vergleich zu dem, was Sie begonnen haben, verschoben hat. Ich sehe keinen Unterschied in der Häufigkeit der Zusammenführung vom zentralen Repository zu Ihrem Arbeitsplatz (und Ihr Projektzweig ist Ihr Arbeitsplatz).

Ich bin in der Regel häufig für die Zusammenführung (mindestens einmal am Tag kann ich auch zu einem anderen für mich geeigneten Zeitpunkt zusammenführen oder wenn ich weiß, dass jemand etwas eingecheckt hat, das sich auf meine Arbeit auswirkt). Es ist viel einfacher, kleine Änderungen zu übernehmen, und wenn Sie ein Problem haben, sind die Leute hilfreicher, wenn Sie sie nach dem fragen, was sie gerade eingecheckt haben, als nach dem, was sie vor einer Woche eingecheckt haben.

Übrigens, ich weiß nicht, was Sie "Break the Build" nennen. Ich neige dazu, in relativ kleinen Schritten zu arbeiten, damit ich einen kompilierbaren Zustand behalte, auch wenn dadurch einige Funktionen beschädigt werden. Und ich führe die Tests durch, damit ich weiß, dass die Zusammenführung nichts kaputt gemacht hat, was funktionieren sollte. Auch hier ist es einfacher, ein Problem zu beheben, wenn es frühzeitig erkannt wird.

Es hängt davon ab, wie gut Sie "nicht aktualisieren" können, wenn jemand anderes den Build bricht. Einerseits möchten Sie so kleine Teile wie möglich aktualisieren. Persönlich aktualisiere ich fast jedes Mal, wenn ich bemerke, dass Updates verfügbar sind. Wenn der Build jedoch unterbrochen wird und es einen Tag dauern wird, bis jemand anderes ihn repariert, möchten Sie in der Zwischenzeit immer noch in der Lage sein, an Ihrer neuen Funktion zu arbeiten.

Ich habe mit Versionskontrollsystemen gearbeitet, die nach Abschluss eines Updates nur sehr schwer zu sichern sind. Bei diesen neige ich dazu, nur kurz vor dem Einchecken zu aktualisieren. Bei besseren Versionskontrollsystemen gibt es wenig Grund, nicht mehrmals pro Tag zu aktualisieren.