私にはモラルの欠落があります。私の会社では、製品スイート全体がメイン ブランチにあり、プロジェクトはメイン (トランク) ブランチから分岐します。配信予定のスプリント (長い 8 週間) が遅れており、2 週間展開できないという問題がありますが、開発は次のスプリントに進む必要があります。
問題は、スプリント 1 で修正が必要なバグがあり、開発が既存のブランチで続行される場合、バグ修正とスプリント 2 の一部が混ざり合って、スプリント 1 のリリースが非常に困難になることです。
一方、既存のブランチから新しいブランチを作成すると、すべてのタスクとバグが失われます。
コード ブランチが 1 つのチーム プロジェクトを共有する方法はありますか?
この状況をどのように処理しますか？私が見逃しているものはありますか？
スプリントごとに新しいチーム プロジェクトに分岐している場合、それは間違っています。1 つの製品のすべてのブランチは、同じチーム プロジェクトに存在する必要があります。
スプリントは、チーム プロジェクトではなく、イテレーションに合わせて調整する必要があります。これにより、作業項目を 1 つのスプリントから別のスプリントに問題なく自由に再割り当てできます。
バグが重大な場合は、スプリント 1 ブランチで修正し、スプリント 2 にマージします。そうすれば、スプリント 2 コードなしでバグをリリースできます。これが最初のスプリント 1 リリースの一部であるか、将来のリリースであるかは関係ありません。
バグが重大でない場合は、スプリント 2 ブランチで修正し、バグを含むスプリント 1 をリリースできます。
スプリントとブランチを 1 対 1 で並べる必要がある理由はありません。3 つのスプリントごとにリリースするだけであれば、3 つのスプリントごとにブランチするだけで簡単に解決できます。リリース管理が得意で、どの変更セットがリリースされたかを正確に把握している場合は、スプリントの結果を変更する必要がある場合に、リリースの数週間後に分岐することもできます。
継続的な展開を真剣に考えたい場合は、トランク ブランチと機能ブランチを持つことを検討する必要があります。機能は、完了したときにのみトランクにマージされます。スプリントごとに複数の機能ブランチがある場合があります。または、新しいコードをデプロイできることを意味する機能トグルを調べますが、ユーザーが何も気付かないようにオフにします。