リリースブランチをマスターにマージする必要があります
私のチームはGit Stable Mainlineブランチモデルを使用しており、最初のリリースブランチを作成しようとしています。これまで読んだことから、リリースブランチはマスターブランチからサイロ化されており、完全にマスターにマージされることはないようです。代わりに、リリースブランチで修正が行われた場合、通常はマスターブランチにチェリーピックされます。現在のリリースを次のリリースの開発から完全に分離したまま、現在のリリースの準備と同時にマスターで次の機能セットを開発できるようにしたいので、これは私にとって意味があります。
これらのリリースブランチをどれくらいの期間保持する必要がありますか？それらを完全にマスターにマージする必要があるケースはありますか？
これらのブランチはどのくらいの期間保持する必要がありますか？
ここで私の心に浮かぶ最初の答えは：
なぜ最初にリリースブランチを作成するのですか？
本番環境で使用するバージョンにサポートを提供できるようにする場合は、そのバージョンが顧客と共存している限り存続する必要があります。 （LTSサポートなど、複数のブランチがあり、少し複雑になる可能性があります）
安定化作業を進行中の新しい開発から分離する場合、バージョンがデプロイされると、そのブランチはもう必要ありません。ここで、これは継続的デリバリーパイプラインを示唆します。バグは次のリリースで可能な限り頻繁に修正されます。マスターブランチを1日に複数回展開する安定したブランチと見なすようにこれをプッシュする人もいます。他の人は彼らのスプリントに同期し、2〜3週間ごとにリリースします。
完全にマスターにマージする必要がありますか？
ご想像のとおり、すべてはwhyに依存します。この分岐戦略を採用しました。継続的デリバリースタイルの場合、ブランチは二度と使用されないため、機能ブランチやバグ修正ブランチと同じように扱い、マスターにマージして忘れてしまう可能性があります。
ただし、LTSスタイルを目指している場合、特にそのようなブランチが複数ある場合は、マージされない可能性があります。ここでは、すべてのリリースブランチに修正を適用し、そのうちの1つから選択して、修正をマスターにマージします。このシナリオで最後に行うことは、マスターからの変更がマスターにプルアップされ、マスターではなく競合が解決される他の機能ブランチと同様に扱うことです。
製品のライフサイクルとチームのワークフローについての知識がなければ、ここでより正確なアドバイスを思いつくことは困難です。