ホットフィックスの処理中の複数のアクティブなリリースに対する適切なGitワークフロー

私の製品に最適なGitワークフローを選択しようとしています。パラメーターは次のとおりです。

• 年に数回のメジャーリリースを行っています。
• 製品の複数のバージョンが同時にアクティブになっています（v10.1、v11.2など）。
• 同時に複数のリリースで作業できるようにする必要があります（v12.1で作業できるようになりましたが、リリースの終わりに達すると、v12.2で作業を開始します）
• 重大なバグが見つかった場合、リリースを修正できる必要があります

これまでのところ、ここで私はそれがうまくいくと思う方法です：

• 単一のリモートリポジトリが使用されます
• マスターからブランチ12.1を作成します
• 12.1に基づいて機能ブランチを作成し、コミットして12.1にマージしてプッシュ
• 将来のリリースで作業を開始する必要がある場合は、12.1に基づいて新しいブランチ12.2を作成します
• その後、12.1の機能で作業する場合、12.1からブランチを作成し、変更をコミットし、12.1と12.2の両方にマージします
• 12.2の機能で作業している場合、12.2からブランチを作成し、変更をコミットし、12.2にのみマージします
• リリース12.1が完了したら、それをマスターにマージし、12.1でマスターブランチにタグ付けします
• 修正プログラムが必要な場合は、それを必要とする最も古いリリースブランチから修正プログラムブランチを作成し、変更をコミットし、そのリリースと影響を受ける可能性がある将来のリリースのすべてのリリースブランチにマージします。最新の安定版リリースブランチが影響を受けた場合は、マスターにマージします。

私はいくつかの懸念があります：

• 特に多くの重複する変更があった場合、古いブランチから新しいブランチへのホットフィックスのマージがスムーズなプロセスになるかどうかはわかりません。競合があるように見える場合は、各ブランチで手動で修正プログラムを適用する方が賢明でしょうか
• 私が見たワークフローモデルは、リリースブランチがあまり生き残っていないようです。いったんリリースがマスターにマージされ、タグが付けられ、削除されます。私の問題は、マスターのタグがすべてある場合、リリースの状態を管理する方法がわからないことです。ブランチで修正する方が簡単なようで、いつでも戻ることができるリリースがあります最新の修正プログラムが含まれています（リリースの修正プログラムにタグを付けることもできます）。マスター内に戻って、修正プログラムが適用されたリリースのコピーを適用し、そのタグを更新する方法があるかどうかはわかりません。

私が見落としているかもしれないことや、私が指定した要件を考慮して物事を達成するより良い方法についてのコメントを歓迎します。

すべてのメジャーリリース（12.0.0）で分岐し、各マイナーリリース（12.1.0）、およびホットフィックス（12.2.1）のマイナーアップデートが行われているようです。正しい？

リリースが出た後、GitFlowでリリースブランチを存続させ続けることができない特定の理由はありません。ただし、複数の分岐ブランチ間の変更を長期間調整することはどのモデルでも難しいという事実を除きます。GitFlowは、1つのライブリリースを維持しつつ、次のリリースを開発する製品に対してもより多くのモデルが作成されたと思われます。

GitFlowに固執し、いくつかの修正を行います。

masterブランチをスキップします。私はこれまでこれを実際に使用したことはありませんでしたが、あなたが作業する方法では直線性を失います。開発の次のメジャーリリースで開発を続けます。マスターを保持することにした場合は、リリースタグをマスターに配置せず、出荷するバイナリを生成したリリースブランチの最後のコミットに配置します。

リリースブランチをマージして開発した後、リリースブランチを捨てないでください。代わりに、次のマイナーリリースと可能なホットフィックスのためにそれらを保持します。リリースのサポートを停止した場合、それらを削除しても大丈夫だと思います。メインコンポーネントrelease / 12にちなんでリリースブランチに名前を付け、その後、サブリリースブランチrelease / 12.1、release / 12.2を作成できます。私はこのレベルの並列処理についてあまり心配する必要はありませんでしたが、おそらくそれが私が試したいことです。この場合、各メジャーリリースブランチを独自のサブGitFlow環境と考えることができます。

複数の将来のメジャーリリースの機能を同時に並行して作業する必要がある場合、次のリリース（13）を開発に、後のバージョン（14、15）に追加の「開発-N」ブランチを追加する必要があります。 。それは一般的に維持するのが非常に難しいようですが、可能です。

主な問題（«複数のリリースで同時に作業できるようにする必要がある[...]»）の可能な解決策は、git worktree add <path> [<branch>]

gitリポジトリは複数の作業ツリーをサポートでき、一度に複数のブランチをチェックアウトできます。
ではgit worktree add、新しい作業ツリーをリポジトリに関連付けられています。

この新しい作業ツリーは、「git init」または「git clone」によって準備された「メイン作業ツリー」とは対照的に、「リンク作業ツリー」と呼ばれます。
リポジトリには、1つのメイン作業ツリー（ベアリポジトリでない場合）と0個以上のリンクされた作業ツリーがあります。

詳細については、SOのこの回答をご覧くださいgit worktree。

あなたはgitflowに精通していると述べました。シナリオに合わせて追加することをお勧めします。古いバージョンをサポートするには、開発ブランチからブランチを作成する必要があります。これらの古いバージョンには、独自のリリース/マスターブランチとホットフィックスブランチも必要です。サポートブランチを新しいサポートブランチと開発ブランチに定期的にマージする必要があります。

メジャーバージョンの開発が分岐すると、これはますます難しくなります。これに特効薬はありません。手動で変更する方が簡単な場合があります。古いバージョンを維持するコストは増加し、ある時点でそれはもう価値がなくなります。

それはすべて、古いバージョンでどのような変更を行っているかによって異なります。バグ修正だけであれば、比較的簡単にマージできます。新しい機能を追加しようとすると、それは難しいでしょう。