クライアントのニーズとより一般的なロードマップのリズムで進化するソフトウェア製品があります。
私たちは SCRUM プロジェクト環境にいるため、新しい機能が製品に導入されることが非常に定期的に発生し、次の選択に直面します。
新機能をリリースしないという選択肢はありません。クライアントは、必要な機能を取得するための長期的なマイルストーン計画を待ちたくありません。また、機能をクライアント モジュールに移動することが常に可能であるとは限りません。変更が必要になる場合もあります。商品の核となる...
この種の制約が与えられた場合の優れた実践についてのフィードバックはありますか?
現在の環境で使用している次のことをお勧めします。計画外の機能をセキュリティ修正のように扱います。
このようにして、計画外の各機能はブランチを取得しますが、新しいリリースを作成してトランクにマージするのに十分な長さしかありません。ほとんどすべての作業を1つの場所（トランク）で実行し、マージ作業を多く行う必要はありません。
あなたが本当にスクラム環境に住んでいるようには聞こえません。スクラムでは、すべてのスプリントの最後にチームを完了させる必要があります。これは、4週間（おそらく1〜2週間）より長くは続かないはずです。したがって、数週間ごとに、とにかく、完全にテストされ、実行され、潜在的に展開可能なシステムが必要です。
私が知っている唯一の方法は、顧客テストと開発者テストの両方の包括的で完全に自動化されたスイートを用意することです（エクストリームプログラミングが規定しているように）。
この場合、なぜブランチが必要になるのかわかりませんが、なぜそれが保守できないのかもわかりません。私の経験では、ブランチの寿命が短いほど良いです。
（'new_feature_branch'）のような新しいブランチは、現在のブランチ（'release_branch'のような）と互換性のない開発作業を実現するためにあります。
したがって、現在のrelease_branchがあまりアクティブでない場合は、新しい機能に使用できます（このプロセスをキャンセルして、この新しい機能の前の状態に戻る必要がある場合に備えて、この新しい機能を開発する前にラベルを定義する必要があります）。
新しいブランチを作成することは、リリースブランチで定期的に（3週間ごとに）マージされてから除外される場合に、優れたソリューションになる可能性があります。release_branchでいくつかのアクティビティ（ホットバグ修正など）がある場合は、特にお勧めします。次に、2つの取り組みを分離しておく必要があります。
基本的に、それはすべてマージワークフローの定義に帰着します。
私が十分に深く対処しなかったと思ういくつかのオプションを詳しく説明したい場合は、コメントを残してください。
私のオフィスでは、通常、任意の時点で 3 つの支店で作業しています。
まれに、4 行目で開発する必要がある場合 (リリース スケジュールが非常に厳しいため) は、サンドボックス コード行を開くことがあります。より一般的には、1 人の開発者が孤立して作業し、メイン ラインがクリアされるまでチェックインしません。
上記の分岐戦略により、すべてのスプリントの終わりに配信を行うことで、主要な機能変更を行うことができました。