it-swarm-eu.dev

Geeigneter 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 Hauptveröffentlichungen pro Jahr, sagen wir höchstens 10
  • Wir haben mehrere Versionen unseres Produkts gleichzeitig aktiv (einige Leute sind in Version 10.1, andere in Version 11.2 usw.)
  • Wir müssen in der Lage sein, an mehreren Releases gleichzeitig zu arbeiten (damit wir an Version 12.1 arbeiten können, aber am Ende der Version beginnen wir gleichzeitig mit der Arbeit an Version 12.2).
  • Wir müssen in der Lage sein, Releases zu reparieren, wenn kritische Fehler gefunden werden

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

  • Es wird ein einzelnes Remote-Repo verwendet
  • Erstellen Sie den Zweig 12.1 vom Master aus
  • Erstellen Sie Feature-Zweige basierend auf 12.1, schreiben Sie sie fest und führen Sie sie wieder zu 12.1, Push, zusammen
  • Sobald wir mit der Arbeit an zukünftigen Versionen beginnen müssen, erstellen Sie einen neuen Zweig 12.2 basierend auf 12.1
  • Wenn Sie von nun an an einem Feature für 12.1 arbeiten, erstellen Sie einen Zweig aus 12.1, übernehmen Sie Änderungen und führen Sie ihn in 12.1 und 12.2, Push, zusammen
  • Wenn Sie an einem Feature für 12.2 arbeiten, erstellen Sie einen Zweig aus 12.2, übernehmen Sie Änderungen und führen Sie ihn nur in 12.2, Push, zusammen
  • Wenn Release 12.1 abgeschlossen ist, führen Sie es mit 12.1 in den Master- und Tag-Master-Zweig ein
  • Wenn ein Hotfix benötigt wird, erstellen Sie einen Hotfix-Zweig aus dem ältesten Release-Zweig, der ihn benötigt, übernehmen Sie Änderungen und führen Sie ihn wieder in alle Release-Zweige für dieses Release und zukünftige Releases ein, die betroffen sein könnten. Wenn der letzte Zweig mit stabiler Version betroffen war, führen Sie ihn in master zusammen.

Ich habe einige Bedenken:

  • Ich bin mir nicht sicher, ob das Zusammenführen von Hotfixes aus alten Zweigen in neue Zweige ein reibungsloser Prozess ist, insbesondere wenn sich viele überlappende Änderungen ergeben haben. Wäre es klüger, in jedem Zweig nur manuell einen Hotfix durchzuführen, wenn es so aussieht, als würde es zu Konflikten kommen
  • Die Workflow-Modelle, die ich gesehen habe, scheinen die Release-Zweige nicht viel am Leben zu erhalten. Sobald sie fertig sind, wird das Release mit dem Master zusammengeführt, markiert und entfernt. Mein Problem dabei ist, dass ich keine gute Idee habe, wie ich den Status der Version verwalten soll, wenn ich nur Tags im Master habe, es einfacher zu sein scheint, sie in einem Zweig zu fixieren, und dann habe ich eine Version, zu der ich immer zurückkehren 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, innerhalb von Master zurückzukehren und irgendwie eine Kopie der Version mit angewendeten Hotfixes zu haben und dieses Tag zu aktualisieren.

Kommentare werden zu Dingen geschätzt, die ich möglicherweise übersehen habe, oder zu besseren Möglichkeiten, Dinge zu erreichen, wenn die von mir angegebenen Anforderungen erfüllt sind.

34
Rocket04

Sie scheinen bei jeder Hauptversion (12.0.0) zu verzweigen und haben dann möglicherweise kleinere Updates für jede (12.1.0) und Hotfixes (12.2.1). Richtig?

Es gibt keinen bestimmten Grund, warum Sie Release-Zweige in GitFlow nach Veröffentlichung eines Releases nicht mehr am Leben erhalten können, außer der Tatsache, dass es für jedes Modell schwierig ist, Änderungen zwischen mehreren divergierenden Zweigen über einen längeren Zeitraum zu koordinieren. Ich nehme an, GitFlow wurde auch mehr für Produkte modelliert, die eine einzige Live-Version beibehalten, während sie die nächste entwickeln.

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

Überspringen Sie den Hauptzweig. Ich habe es bisher nicht praktisch angewendet, und es würde seine Linearität verlieren, wie Sie arbeiten. Setzen Sie die Entwicklung bei der nächsten Hauptversion fort. Wenn Sie sich dafür entscheiden, den Master beizubehalten, setzen Sie keine Release-Tags auf den Master, sondern setzen Sie sie auf das letzte Commit im Release-Zweig, der die von Ihnen gelieferte Binärdatei erzeugt hat.

Werfen Sie die Release-Zweige nicht weg, nachdem Sie sie wieder zusammengeführt haben, um sie zu entwickeln. Bewahren Sie sie stattdessen für die nächste kleinere Version und mögliche Hotfixes auf. Wenn Sie jemals aufhören, eine Version zu unterstützen, ist es wahrscheinlich in Ordnung, sie zu löschen. Sie können Release-Zweige nach ihrer Hauptkomponente, Release/12, benennen und dann Unter-Release-Zweige, Release/12.1, Release/12.2, 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 Hauptversionszweig 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 alles für spätere Versionen (14, 15) für zusätzliche "Develop-N" -Zweige beibehalten . Das scheint im Allgemeinen sehr schwer aufrechtzuerhalten zu sein, wäre aber möglich.

12
axl

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 [...]") darin besteht, ein - zu tun) git worktree add <path> [<branch>]

Ein Git-Repository kann mehrere Arbeitsbäume unterstützen, sodass Sie mehr als einen Zweig gleichzeitig auschecken können.
Mit git worktree add wird dem Repository ein neuer Arbeitsbaum zugeordnet.

Dieser neue Arbeitsbaum wird als "verknüpfter Arbeitsbaum" bezeichnet, im Gegensatz zum "Hauptarbeitsbaum", der von "git init" oder "git clone ".
Ein Repository hat einen Hauptarbeitsbaum (wenn es kein nacktes Repository ist) und null oder mehr verknüpfte Arbeitsbäume.

Siehe this SO answer für eine detaillierte Einführung zu git worktree.

4
sentenza

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 müssen auch über eigene Release-/Master-Zweige und Hotfix-Zweige verfügen. Sie müssen Ihre Support-Zweige regelmäßig mit den neueren Support-Zweigen und dem Entwicklungszweig zusammenführen.

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

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

2
Gábor Angyal