Was sind die Vorteile von "Staircase" Branching?

Question

Ich bin auf ein Projekt gestoßen, bei dem wir die Treppenhausverzweigung verwenden. Um dies zu verdeutlichen, ist dies der Ansatz, bei dem Code für die Entwicklung verzweigt wird und wenn die Entwicklung abgeschlossen ist, anstatt zurück zu einer Amtsleitung/Hauptleitung zu schneiden, wird der Entwicklungszweig als der Live-Code festgelegt und ein neuer Zweig wird daraus genommen. Dies geht ad infinitum weiter.

Ich persönlich bevorzuge den Schnitt zurück zu einem Trunk-Ansatz, um einen einzigen "Live" -Codeset zu erhalten. Ich frage mich jedoch, ob es irgendwelche konkurrierenden Vorteile für den Treppenhausansatz gibt.

Danke, Tom

Answer 1

Diese Methode wird Sie in den Köcher beißen, sobald Sie mehrere Zweige erstellen und gleichzeitig entwickeln wollen. Wenn Sie die Verbindung zum Stamm wieder herstellen, können Sie parallele Verzweigungen verwenden und diese Zweige einzeln zusammenführen.

Answer 2

Es gibt ein paar (potentiell minor) Vorteile dieses Ansatzes.

Die überzeugendsten Vorteile ergeben sich aus der fehlenden Notwendigkeit, Änderungen in den Hauptzweig zusammenzuführen. Dies macht es einfach, eine Verzweigung (den alten "Stamm") für die Version zu behalten, in der Sie verzweigt haben, und es erfordert auch keine Mühe auf dem Dev-Zweig weiterzumachen. In Wirklichkeit ist das nicht anders als einen Live-Trunk zu haben und sich für eine Veröffentlichung zu markieren oder zu verzweigen - außer dass du deine Entwicklung "verschiebst", anstatt deinen getaggten Zweig zu bewegen. Dies macht es einfacher, saubere Zweige mit weniger Aufwand zu pflegen, da es nicht nötig ist, für jedes Release einen neuen Zweig zu "markieren" - es geschieht einfach automatisch. Dies ist jedoch eine geringfügige Zeitersparnis.

Meiner Erfahrung nach gibt es jedoch einen potenziellen Nachteil. Ich habe oft festgestellt, dass es für Entwickler oft einfacher ist, Binärkompatibilität in Bibliotheken zu unterbrechen, da Sie immer an einer Entwicklungskopie arbeiten und jedes "Release" ein eigener Zweig davon ist. Da beim Zusammenführen mit einem Stamm kein Aufwand erforderlich ist, kann es leicht passieren, dass eine API versehentlich unterbrochen wird. Dies ist keine große Sorge IMO, aber ist etwas zu beachten, da es keine Anstrengung während des Merge-Prozesses (die scheint, wo die meisten dieser Fehler oft entdeckt werden) ist.

Answer 3

Ich glaube, es ist ein Weg, um das Zurückrollen zu erleichtern, und ein wenig klarer die Unterschiede zwischen den Versionen. Es ist auch einfacher, eine frühere Version zu entwickeln (z. B. eine Version für Entwickler und eine Version für Designer).

Ich selbst bevorzuge den anderen Ansatz mit Tags, die die Checkpoints angeben. Ich benutze Git, und der Prozess des Verzweigens und der Ausführung dieser Art von Dingen ist wirklich gut damit gebaut.

Answer 4

Gleich zu Beginn der ersten Treppe befinden Sie sich in der gleichen Position wie bei der Entwicklung der ersten Version. dieser ist es, keine späten Entscheidungen darüber, was zurück in den Hauptstamm zu bewegen. Der Build von der Treppe ist dein letzter Kandidat.

Strafe, wenn viele Änderungen und Fix in Original haben Sie zusammen zu tun, und das könnte störend sein. Ich vermute, dass es einen Break-Even-Punkt geben könnte, wenn die Änderungsrate für die neue Version und die Rate des Patches in der alten Treppe suboptimal sind.