Sollten Release-Zweige jemals zum Master zusammengeführt werden

Mein Team verwendet das Git Stable Mainline-Verzweigungsmodell und wir sind dabei, den ersten Release-Zweig zu erstellen. Nach dem, was ich bisher gelesen habe, klingt es so, als ob Release-Zweige vom Master-Zweig getrennt und nie wieder vollständig zum Master zusammengeführt werden. Wenn stattdessen ein Fix für den Release-Zweig vorgenommen wird, wird dieser normalerweise in den Master-Zweig zurückgesucht. Dies ist für mich sinnvoll, da Sie die aktuelle Version vollständig von der Entwicklung der nächsten Version trennen möchten und gleichzeitig mit der Vorbereitung der aktuellen Version die nächsten Funktionen auf dem Master entwickeln möchten.

Wie lange sollten diese Release-Zweige aufbewahrt werden? Gibt es Fälle, in denen sie vollständig wieder zum Master zusammengeführt werden sollten?

git release-management

Die von Ihnen verwendete Verzweigungsstrategie hängt vollständig vom Workflow Ihres Unternehmens und den spezifischen Anforderungen ab.

— Robert Harvey

How long should these release branches be kept around for?Solange Sie erwarten, eine Fehlermeldung für diese Version zu erhalten, die Sie aus dem Quellcode reproduzieren möchten. Ich würde überhaupt keinen Release-Zweig entfernen, da ein Zweig einen kleinen Kilobyte-Footprint auf dem Server hat. Nur das Delta kostet Festplattenspeicher

— k3b

cherry pickingJedes Commit auf dem Release- Zweig in Master oder merging Release in Master ist technisch dasselbe. Akzeptieren Sie, dass Sie das cherry picksin der Git-Historie nicht "sehen" . Daher würde ich es vorziehen , wenn mergingjeder Fix mit der Option gits wieder in den Master zurückgeführt wird , --no-ffsodass im Verlauf der zusätzliche Release-Zweig angezeigt wird .

— Timothy Truckle

meinst du das: bitsnbites.eu/a-stable-mainline-branching-model-for-git er ausdrücklich sagt nie den Release - Zweig zu fusionieren zurück

— Ewan

Vielen Dank für das Feedback an alle. @Ewan Ja, aber ich habe auch einige allgemeine Git-Dokumentationen von Microsoft gelesen und es sah so aus, als hätten sie nie den gesamten Release-Zweig wieder zum Master zusammengeführt.

Wie lange sollten diese Zweige aufbewahrt werden?

Die erste Antwort, die mir hier einfällt, lautet:

Warum erstellen Sie überhaupt einen Release-Zweig?

Wenn Sie eine Version im Produktionsbetrieb unterstützen möchten, sollte sie so lange funktionieren, wie diese Version bei Ihren Kunden lebt. (Sagen wir LTS-Unterstützung, Sie könnten mehrere solcher Zweige haben, was die Dinge etwas komplexer macht.)

Wenn Sie Stabilisierungsarbeiten von laufenden Neuentwicklungen trennen, benötigen Sie diesen Zweig nach der Bereitstellung der Version nicht mehr wirklich. Hier würde dies auf eine kontinuierliche Lieferpipeline hindeuten. Alle Fehler werden in der nächsten Version behoben, die so häufig wie möglich auftreten würde. Einige drängen darauf, den Hauptzweig als den stabilen Zweig zu betrachten, der mehrmals täglich bereitgestellt wird. Andere werden mit ihren Sprints synchronisiert und alle zwei bis drei Wochen veröffentlicht.

Sollten Sie es wieder vollständig in Master zusammenführen?

Wie Sie vermuten, hängt alles davon ab, warum Sie diese Verzweigungsstrategie übernommen haben. Da der Zweig nie wieder verwendet wird, sollten Sie ihn wie einen Feature- oder Bugfix-Zweig behandeln. Wahrscheinlich würden Sie ihn wieder mit dem Master zusammenführen und ihn vergessen.

Wenn Sie jedoch den LTS-Stil anstreben, werden Sie ihn wahrscheinlich nicht wieder zusammenführen, insbesondere wenn Sie mehrere solcher Zweige haben. Hier würden Sie den Fix auf alle Release-Zweige anwenden und einen von ihnen auswählen , um diesen Fix wieder in Master zusammenzuführen. In diesem Szenario möchten Sie es als letztes wie jeden anderen Feature-Zweig behandeln, in den Änderungen vom Master übernommen und Konflikte dort und nicht im Master gelöst werden.

Ohne mehr über Ihren Produktlebenszyklus und den Workflow Ihres Teams zu wissen, ist es schwierig, hier eine genauere Beratung zu finden.

— Newtopian
quelle

Dies bedeutet, dass der Zweig nach dem Zusammenführen verloren geht, was nicht der Fall ist. Der Release-Zweig sollte auch im LTS-Modus im Master zusammengeführt werden. Es gibt keinen Grund, Release-Zweige nicht zusammenzuführen.

— Basilevs

Es geht nicht darum, dass Zweige verloren gehen, sondern vielmehr darum, einen zum Nachdenken zu zwingen. Durch systematisches Zusammenführen der LTS-Zweige würden sie Duplikate für alle aktiven LTS-Zweige zusammenführen. Eine Fehlerbehebung muss nur einmal mit der Hauptversion und wahrscheinlich nicht aus einem LTS-Zweig zusammengeführt werden, da sich die neueste Version wahrscheinlich noch nicht in LTS befindet und näher am Status des Hauptzweigs liegt. In diesem Szenario würde man aus der neuesten Version auswählen, der LTS-Zweig selbst würde fast nie an den Master weitergeleitet. Dass der Zweig nach einer Zusammenführung verloren geht oder nicht, spielt keine Rolle.

— Newtopian

Warum sollte man es vorziehen, unsichere Cherry-Picks zu duplizieren, um eine sichere Zusammenführung zu erreichen? Mit "sicher" meine ich die kryptografisch geschützte Verfolgung und Weitergabe von Änderungen.

— Basilevs

Ein ähnlicher Ansatz funktioniert ohne Cherry-Picks, indem der Fix auf den ältesten Zweig angewendet und von älter zu neuer zusammengeführt wird. Wenn Kirschpickel vermieden werden können, warum sollten Sie sie verwenden? Ich scheine etwas im Stable Mainline-Modell falsch zu verstehen ...

— Basilevs