Ich versuche, einen Git-Workflow auszuwählen, der für unser Produkt am besten geeignet ist. Hier sind die Parameter:
Bisher denke ich, dass es so funktionieren könnte:
Ich habe einige Bedenken:
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.
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.
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.
Mitgit 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
.
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.