並列リリースで作業するときのGitでのワークフロー

Question

feature/bugfixという概念を使用しています.Gitでブランチを開発してリリースしていますが、私たちはマスターブランチを維持していません。

QAのビルドと運用リリースの最終ビルドはリリースブランチから行い、スナップショットは開発ブランチから取得します。

Release 1 
Release 2 

主な問題：Release 1からRelease 2への変更をマージ

は、我々が現在開発中の2つのリリースを持っていると言います。我々は通常、生産に展開されたRelease 1の後に大きなマージを行います。この結果、いくつかのマージの競合が発生します。

これを防止するための最良のワークフローは何ですか？

リリース1の機能/バグフィックスブランチをRelease 1とRelease 2の開発ブランチにマージすることを考えてください。これは開発者のための追加作業を意味します。

Answer 1

リリースブランチからのマージ（git merge）は、一般的にベストプラクティスではありません。コミットによっては、1つのリリースでのみ実行され、別のリリースには適用されないものもあります。

Cherry-pickingは、通常、マージする予定がない2つのブランチの間で実行されます（各リリースブランチには独自の独立した履歴があります）。
まだコンフリクトがありますが、少なくともその起源は見つけやすくなります（チェリーピックされた特定のコミットになります）。
同じ考え方がバグ修正ブランチに適用されます（すべての修正が次のリリースブランチに適用されるわけではないため、チェリーピッキング）。
機能ブランチをマージすることもできます。