ホットフィックスの処理中の複数のアクティブリリースに適したGitワークフロー
私の製品に最も適したGitワークフローを選択しようとしています。パラメータは次のとおりです。
- 年間数回のメジャーリリースを行っていますが、最大で10とします
- 製品の複数のバージョンが同時にアクティブになっている（一部のユーザーは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のマスターおよびタグマスターブランチにマージします。
- 修正プログラムが必要な場合は、それを必要とする最も古いリリースブランチから修正プログラムブランチを作成し、変更をコミットして、影響を受ける可能性のあるそのリリースおよび将来のリリースのすべてのリリースブランチにマージします。最新の安定版リリースのブランチが影響を受けた場合は、masterにマージします。
私はいくつかの懸念があります：
- 特に多くの重複する変更があった場合、古いブランチから新しいブランチへのホットフィックスのマージがスムーズなプロセスになるかどうかはわかりません。競合があるように見える場合に、各ブランチで手動でホットフィックスを行う方が賢明でしょうか
- 私が見たワークフローモデルは、リリースブランチを存続させることができないようです。完了すると、リリースはマスターにマージされ、タグが付けられ、削除されます。私の問題は、私が持っているすべてがマスターのタグであり、ブランチで修正するのが簡単で、その後いつでも戻ることができるリリースがある場合、リリースの状態を管理する方法がよくわからないことです最新の修正プログラムが含まれている（リリースの修正プログラムにタグを付けることもできます）。私がマスター内に戻って、どういうわけかホットフィックスが適用されたリリースのコピーを持ち、そのタグを更新する方法があるかどうかわかりません。
私が見落としたかもしれないこと、または私が指定した要件を前提として物事を達成するためのより良い方法についてコメントをいただければ幸いです。
メジャーリリース（12.0.0）ごとに分岐しているようで、それぞれのマイナーアップデート（12.1.0）とホットフィックス（12.2.1）を持っているようです。正しい？
どのモデルでも、複数の分岐ブランチ間の変更を長期間調整することが難しいという事実を除いて、リリースがリリースされた後、GitFlowでリリースブランチを存続させることができない特定の理由はありません。また、GitFlowは、次の開発中に単一のライブリリースを維持する製品用にさらにモデル化されたと思います。
私はGitFlowに固執し、いくつかの修正を加えます。
Masterブランチをスキップします。これまでのところ、これを実際に使用したことはありません。そのため、作業方法の直線性が失われます。開発の次のメジャーリリースで開発を続けます。マスターを維持することにした場合は、リリースタグをマスターに置かず、出荷するバイナリを生成したリリースブランチの最後のコミットに配置します。
リリースブランチをマージして開発した後、リリースブランチを捨てないでください。代わりに、次のマイナーリリースと可能なホットフィックスのためにそれらを保持します。リリースのサポートを停止した場合は、それらを削除しても問題ないと思います。リリースブランチの名前は、メインコンポーネントrelease/12にちなんで付け、次にサブリリースブランチrelease/12.1、release/12.2を作成します。私はこのレベルの並列処理についてあまり心配する必要はありませんでしたが、おそらくそれを試してみました。この場合、各メジャーリリースブランチを独自のサブGitFlow環境と考えることができます。
将来のいくつかのメジャーリリースの機能を同時に並行して作業する必要がある場合は、次のリリース（13）を開発に、それ以降のバージョン（14、15）を追加の "develop-N"ブランチに維持する必要があるかもしれません。 。これは一般に維持するのが非常に難しいように見えますが、可能です。
あなたの主な問題の考えられる解決策（"同時に複数のリリースで作業できるようにする必要がある[...]"）がおかしくなっているようです- git worktree add <path> [<branch>]
gitリポジトリは複数の作業ツリーをサポートできるため、一度に複数のブランチをチェックアウトできます。
git worktree addを使用すると、新しい作業ツリーがリポジトリに関連付けられます。この新しい作業ツリーは、「
git init」または「git clone」によって作成された「メイン作業ツリー」ではなく、「リンクされた作業ツリー」と呼ばれます。
リポジトリには、1つのメイン作業ツリー（ベアリポジトリでない場合）と0個以上のリンクされた作業ツリーがあります。
git worktreeの詳細については、 this SO answer を参照してください。
あなたはgitflowに精通していると述べました。私はあなたのシナリオにそれを採用することをお勧めします。古いバージョンをサポートするには、開発ブランチからブランチを作成する必要があります。これらの古いバージョンには、独自のリリース/マスターブランチとホットフィックスブランチも必要です。サポートブランチを新しいサポートブランチと開発ブランチに定期的にマージする必要があります。
メジャーバージョンの開発が分かれるにつれて、これはさらに難しくなります。これには特効薬はありません。手動で変更する方が簡単な場合があります。古いバージョンを維持するためのコストは増加し、いつかは価値がなくなります。
古いバージョンでどのような変更を加えているかによります。バグ修正のみであれば、マージは比較的簡単です。新しい機能を追加しようとすると、難しいでしょう。