通常、リリース バージョンの直後にメイン コードラインに切り替え、製品が十分に安定するまでこれに取り組みます。この時点で、次のメジャー バージョンのコードラインに分岐し、最後の仕上げを追加します。
次のメジャー バージョン ブランチですぐに作業を開始することの何が問題になっていますか? 開発の最後の忙しい日々ではなく、最初から最終的なビルド/テスト プロセスを準備することができました。
ありがとう。
質問する
195 次
1 に答える
1
「リリースバージョン」とは、「リリースブランチ」があることを意味していると思います。質問は、多くの「リリースブランチ」と「メインブランチ」ではなく、「リリースブランチ」だけを持たない理由だと思います。
「ベストプラクティス」は、方法論、要件、チームのサイズと構造 (およびおそらくソース管理ソフトウェア) に大きく依存します。たとえば、非常に単純なモデルであっても、通常の開発作業を並行して継続する場所が必要です。安定化作業。
したがって、安定化作業が開始された後に「リリース ブランチ」しかない場合、安定化プロセスが台無しになるため、新しいコードをブランチに追加することはできません。そのため、安定化に直接関与していないエンジニアはチェックインできません。
私は通常、「メイン」ブランチを私の理想的な開発ラインと考えています。これは、開発ブランチからいくつかの最低限の正確性基準を満たしたコードがマージされる場所です。これは、「リリース ブランチ」で行われたバグ修正などのコードもある場所でもあります。合併した
私は、開発者が好きなようにコードを配置できる正確性の基準が少ない開発ブランチを 1 つ以上持っています (実際にはチームの構造によって異なります)。開発ブランチのコードが一定の成熟度に達すると、MAIN にマージされます。
MAIN のコードが再び私の理想的な成熟度に達したら、安定化作業を継続するリリース ブランチを作成します。時々、バグ修正を含むリリース ブランチのコードが MAIN ブランチにマージされます。
MS TFS branchign ガイダンスを確認することをお勧めします。
perforceのこのホワイトペーパーも
于 2012-04-20T07:12:26.387 に答える