Angemessener Git-Workflow für mehrere aktive Releases beim Umgang mit Hotfixes

Ich versuche, einen Git-Workflow auszuwählen, der für unser Produkt am besten geeignet ist. Hier sind die Parameter:

• Wir machen ein paar Hauptversionen pro Jahr, sagen wir höchstens 10
• Es sind mehrere Versionen unseres Produkts gleichzeitig aktiv (einige Benutzer sind mit Version 10.1, andere mit Version 11.2 usw.).
• Wir müssen in der Lage sein, an mehreren Releases gleichzeitig zu arbeiten (also könnten wir an Version 12.1 arbeiten, aber wenn wir am Ende des Releases angelangt sind, beginnen wir gleichzeitig mit der Arbeit an Version 12.2).
• Wir müssen in der Lage sein, Releases zu hotfixen, wenn kritische Fehler gefunden werden

Bisher denke ich, dass es so funktionieren könnte:

• Single Remote Repo wird verwendet
• Erstellen Sie den Zweig 12.1 aus dem Master
• Erstellen Sie Feature-Zweige auf der Basis von 12.1, schreiben Sie sie fest und fügen Sie sie wieder in 12.1 ein
• Wenn wir an einer zukünftigen Version arbeiten müssen, erstellen Sie einen neuen Zweig 12.2, der auf 12.1 basiert
• Wenn Sie von nun an an einem Feature für 12.1 arbeiten, erstellen Sie einen Zweig aus 12.1, schreiben Sie die Änderungen fest und führen Sie die Änderungen in 12.1 und 12.2 zusammen, und drücken Sie
• Wenn Sie an einem Feature für 12.2 arbeiten, erstellen Sie einen Zweig aus 12.2, schreiben Sie die Änderungen fest und führen Sie nur in 12.2 zusammen, und drücken Sie
• Wenn Release 12.1 abgeschlossen ist, führen Sie es in Master und Tag Master Branch mit 12.1 zusammen
• Wenn ein Hotfix benötigt wird, erstellen Sie einen Hotfix-Zweig aus dem ältesten Release-Zweig, der diesen benötigt, schreiben Sie die Änderungen fest und führen Sie ihn in allen Release-Zweigen für dieses Release und zukünftige Releases zusammen, die davon betroffen sein könnten. Wenn der letzte Zweig der stabilen Version betroffen war, führen Sie ihn in master zusammen.

Ich habe ein paar Bedenken:

• Ich bin mir nicht sicher, ob das Zusammenführen von Hotfixes aus alten Zweigen in neue Zweige ein reibungsloser Prozess sein wird, insbesondere wenn sich viele Änderungen überschneiden. Wäre es sinnvoller, in jedem Zweig nur einen manuellen Hotfix durchzuführen, wenn Konflikte auftreten?
• Die Arbeitsablaufmodelle, die ich gesehen habe, scheinen Release-Zweige nicht viel am Leben zu erhalten, sobald die Release fertig ist, wird sie in master zusammengeführt, markiert und entfernt. Mein Problem dabei ist, dass ich keine gute Idee habe, wie ich den Status der Veröffentlichung verwalten soll, wenn alles, was ich habe, Tags in master sind, in einem Zweig einfacher zu reparieren scheint und dann eine Veröffentlichung habe, auf die ich immer zurückgreifen kann Das hat den neuesten Hotfix (ich kann sogar die Hotfixes in der Version markieren). Ich bin mir nicht sicher, ob es eine Möglichkeit gibt, in Master zurückzukehren und irgendwie eine Kopie der Version mit angewendeten Hotfixes zu haben und dieses Tag zu aktualisieren.

Kommentare zu Dingen, die ich möglicherweise übersehen habe, oder zu besseren Methoden, um die von mir festgelegten Anforderungen zu erfüllen, sind willkommen.

Sie scheinen mit jeder Hauptversion (12.0.0) zu verzweigen und haben dann mögliche kleinere Aktualisierungen (12.1.0) und Hotfixes (12.2.1). Richtig?

Es gibt keinen bestimmten Grund, warum Sie Release-Zweige in GitFlow nach einer Veröffentlichung nicht am Leben erhalten können, abgesehen von der Tatsache, dass die Koordination von Änderungen zwischen mehreren divergierenden Zweigen für eine lange Zeit bei keinem Modell schwierig ist. Ich nehme an, GitFlow wurde auch eher für Produkte entwickelt, die eine einzige Live-Version beibehalten, während die nächste entwickelt wird.

Ich würde bei GitFlow bleiben und ein paar Änderungen vornehmen;

Überspringen Sie den Hauptzweig. Bisher hatte ich keine praktische Verwendung davon und es würde seine Linearität verlieren, wie Sie arbeiten. Setzen Sie die Entwicklung für die nächste Hauptversion von Develop fort. Wenn Sie sich dafür entscheiden, master zu behalten, setzen Sie keine Release-Tags auf master, sondern setzen Sie sie beim letzten Commit auf den Release-Zweig, der die Binärdatei erzeugt hat, die Sie versenden.

Werfen Sie die Release-Zweige nicht weg, nachdem Sie sie zur Entwicklung wieder zusammengeführt haben. Bewahren Sie sie stattdessen für die nächste kleinere Version und mögliche Hotfixes auf. Wenn Sie jemals aufhören, eine Veröffentlichung zu unterstützen, ist es wahrscheinlich in Ordnung, sie zu löschen. Sie können Release-Zweige nach ihrer Hauptkomponente, Release / 12, benennen und anschließend Sub-Release-Zweige, Release / 12.1, Release / 12.2, daraus erstellen. Ich musste mir nicht allzu viele Sorgen um diese Parallelität machen, aber das würde ich wahrscheinlich versuchen. In diesem Fall können Sie sich jeden Major Release Branch als eine eigene Sub-GitFlow-Umgebung vorstellen.

Wenn Sie parallel an Funktionen für mehrere zukünftige Hauptversionen gleichzeitig arbeiten müssen, müssen Sie möglicherweise die nächste (13) für die Entwicklung und alle für spätere Versionen (14, 15) für zusätzliche "Develop-N" -Zweige beibehalten . Das scheint im Allgemeinen sehr schwer beizubehalten, wäre aber möglich.

Es scheint, dass eine mögliche Lösung für Ihr Hauptproblem ( «Wir müssen in der Lage sein, an mehreren Releases gleichzeitig zu arbeiten [...]» ) agit worktree add <path> [<branch>]

Ein Git-Repository kann mehrere Arbeitsbäume unterstützen , sodass Sie mehrere Zweige gleichzeitig auschecken können .
Mit git worktree addwird dem Repository ein neuer Arbeitsbaum zugeordnet.

Dieser neue Arbeitsbaum wird als "verknüpfter Arbeitsbaum" bezeichnet, im Gegensatz zu dem durch " git init" oder " git clone" erstellten "Hauptarbeitsbaum " .
Ein Repository verfügt über einen Hauptarbeitsbaum (wenn es kein nacktes Repository ist) und null oder mehr verknüpfte Arbeitsbäume.

In dieser SO-Antwort finden Sie eine ausführliche Einführung zu git worktree.

Sie haben erwähnt, dass Sie mit gitflow vertraut sind. Ich schlage vor, es für Ihr Szenario hinzuzufügen. Sie müssen Zweige aus Ihrem Entwicklungszweig erstellen, um ältere Versionen zu unterstützen. Diese älteren Versionen benötigen außerdem eigene Release- / Master-Zweige und Hotfix-Zweige. Sie müssen Ihre Supportzweige regelmäßig in die neueren Supportzweige und den Entwicklungszweig zusammenführen.

Da die Entwicklung der Hauptversionen divergiert, wird dies immer schwieriger. Es gibt keine Silberkugel dafür. Manchmal ist es einfacher, Änderungen manuell vorzunehmen. Die Kosten für die Wartung älterer Versionen steigen und werden sich irgendwann nicht mehr lohnen.

Es hängt alles davon ab, welche Art von Änderungen Sie an Ihren älteren Versionen vornehmen. Wenn nur Bugfixing, das ist relativ einfach zu verschmelzen. Wenn Sie versuchen, neue Funktionen hinzuzufügen, wird dies schwierig.