リリースブランチをマスターにマージする必要があります

私のチームはGit Stable Mainlineブランチモデルを使用しており、最初のリリースブランチを作成しようとしています。これまで読んだことから、リリースブランチはマスターブランチからサイロ化されており、完全にマスターにマージされることはないようです。代わりに、リリースブランチで修正が行われた場合、通常はマスターブランチにチェリーピックされます。現在のリリースを次のリリースの開発から完全に分離したまま、現在のリリースの準備と同時にマスターで次の機能セットを開発できるようにしたいので、これは私にとって意味があります。

これらのリリースブランチはどのくらいの期間保持する必要がありますか？それらを完全にマスターに戻す必要がある場合はありますか？

これらのブランチはどのくらいの期間保持する必要がありますか？

ここで私の心に浮かぶ最初の答えは：

最初にリリースブランチを作成するのはなぜですか？

本番環境で使用するバージョンにサポートを提供できるようにする場合は、そのバージョンが顧客と共存する限り存続する必要があります。（LTSサポートなど、複数のブランチがあり、少し複雑になります）

安定化作業を進行中の新しい開発から分離する場合、バージョンがデプロイされたら、そのブランチはもう必要ありません。ここで、これは継続的デリバリーパイプラインを示唆します。バグは次のリリースで修正されますが、可能な限り頻繁に発生します。マスターブランチを1日に複数回展開する安定したブランチと見なすようにこれを推進する人もいます。他の人は彼らのスプリントに同期し、2〜3週間ごとにリリースします。

それを完全にマスターにマージする必要がありますか？

ご想像のとおり、この分岐戦略を採用した理由はすべて異なります。継続的デリバリースタイルの場合、ブランチは二度と使用されないため、機能ブランチやバグ修正ブランチと同じように扱い、マスターにマージして忘れてしまう可能性があります。

ただし、LTSスタイルを目指している場合、特にそのようなブランチが複数ある場合は、マージされない可能性があります。ここで、修正をすべてのリリースブランチに適用し、そのうちの1つからチェリーピックして、その修正をマスターにマージします。このシナリオで最後に行うことは、マスターからの変更がマスターにプルアップされ、マスターではなく競合が解決される他の機能ブランチと同様に扱うことです。

製品のライフサイクルとチームのワークフローについての知識がなければ、ここでより正確なアドバイスを思いつくことは困難です。