あなたが説明したシナリオで実行する必要がある手順は、セットアップした開発環境とツールに 100% 依存していると言えます。
ソース コードのバージョン管理に Perforce を使用して、リリースが開発作業から分離され、すべての開発ブランチが単一の「受け入れ」ブランチから派生するブランチ システムをセットアップしました。各ブランチは、単一の問題、または非常に密接に関連する問題のセットに使用されます。変更が受け入れブランチに統合されるまで、ブランチで他の課題に取り組むことはできません。
はい、多くの支店があるということです。はい、多くの同期 (作業ブランチまでの承認) と統合 (作業ブランチから承認まで) を行っています。しかし、あるタスクから別のタスクに簡単に切り替えたり、テストビルドに戻ったり、互いに噛み合っている 2 つの問題を発見したりできるようになると、その価値は計り知れません。
開発が (独自のテストを含め) 完了した後、問題は QA チームによってテストされます。まず、独自のブランチで分離します。その後、受け入れブランチに統合され、独立した問題が互いに噛み合っている問題を見つけるために回帰テストが行われます。このようにリリースのすべての問題が承認に統合されると、QA チームによって完全な回帰テストと新機能テストが実行されます。
したがって、受け入れブランチは常にアプリの開発の "最新" の状態です。
このセットアップでは、説明したシナリオは次のように展開されます。
現在のタスクはそのままにしておきます。コンピューターがクラッシュしたときに失われないように、未解決の変更をチェックインしてください。それがそのブランチの毎日のビルドを中断することを意味する場合、コンパイル エラーを簡単に修正できない限り、私はチェックインしません。(私たちのアプリケーション スイートには多くのアプリがあり、私の変更は私が取り組んでいるアプリでコンパイルされる可能性がありますが、スイート内の他のアプリのコンパイルを壊す可能性があることに注意してください)ビルド プロセスを中断してはなりません。
「空の」ブランチ (現在開発作業に使用されていないブランチ) を見つけるか、すべてのブランチが使用されている場合は、新しいブランチを作成します。
受け入れブランチと選択した作業ブランチを強制的に同期して、マシンが両方のブランチで最新の状態になることが保証されるようにします。
受け入れブランチの最新の状態を作業ブランチに同期 (必要に応じて強制) し、選択した作業ブランチが受け入れブランチと同じになるようにします。
IDE でそのブランチのアプリケーション スイートを開き、デバッグして解決します。作業部門に提出してください。
作業ブランチでそれを確認するよう QA に伝えます。彼らがそれに満足している場合は、受け入れられるまで変更を統合して、テストを続行できるようにします。
以前に作業していたブランチのアプリケーション スイートで作業するために IDE を切り替えます。
すすいで繰り返します。