git flowビジネス チームが次のリリースに含まれる機能を制御したい場合、標準的な処理は理想的ではありません。しかし、他の分岐メカニズムでも同じ問題が発生します。
のデフォルトの構造git flowは、新しい機能ごとに機能ブランチを作成することです。新しい機能のビルド (およびテスト) が完了したら、ブランチを開発ブランチにマージしてから、機能ブランチを削除します。その後、この機能は次のリリースに含まれます。
機能を次のリリースに含めない場合は、機能ブランチを開発ブランチにマージしないでください。それが含まれないようにする最善の方法です。また、他の開発者が新しい機能を使用する (または必要とする) コードを作成するのを防ぎます。
チェリーピッキングはお勧めしません。まず、機能は複数のコミットを持つことができ (そして頻繁にそうなる)、そのうちの 1 つを忘れがちです。次に、機能 B が機能 A に追加されたコードを使用し、管理者が機能 A をリリースせずに機能 B をリリースしたい場合、機能 B が壊れていることに気付く可能性があります。そして、それらの依存関係は必ずしも簡単に見つけられるわけではありません。
経営陣が新しい機能を優先したいのは理にかなっていますが、各機能は、完了 (およびテスト) 後すぐに開発ブランチにマージする必要があります。
各機能に独自のブランチがある場合は、その機能ブランチをマージするだけです。