プロジェクトのブランチを作成すると、次の場合に役立ちます。

プロジェクトのブランチを作成するには、新しい開発パスを作成します。

プロジェクトのブランチを作成する際に従うメインのモデルがあります。

リリースに基づいたブランチ作成モデルでは、プロジェクトの内容 (フィーチャー、拡張機能、欠陥) が静的で明確であるという傾向があります。一般に、完全なプロジェクトは、開発、テスト、リリースというステージをたどります。

すべての開発アクティビティは、プロジェクトのメイン トランクで実施されます。リリース候補はチェックポイントとして識別され、プロジェクト ブランチで完成されます。バグの修正や安定化のための開発作業は、プロジェクトのメイン トランクで続行され、変更パッケージの適用を使用してリリース候補のブランチに移行されます。

このタイプのブランチ モデルは、完全なバージョンが運用環境にリリースされる開発環境に適しています。このモデルを使用する場合は、後で大規模な結合が必要とならないように、ブランチの数を制限することをお勧めします。

プロジェクトに基づいたブランチ作成モデルでは、プロジェクトの内容 (フィーチャー、拡張機能、欠陥) が動的である傾向があり、サブプロジェクト (フィーチャー、拡張機能、欠陥で構成) が最後まで絶え間なく追加または削除されます。プロジェクトは、段階的に運用環境にリリースされます。通常このタイプの開発では、最初のロールアウト以降にプロジェクト全体がリリースされることがなく、運用環境に対して毎週のように更新が行われる傾向があります。

すべての開発は、最新の運用環境チェックポイントから作成されたプロジェクト ブランチで実行されます。プロジェクト ブランチで行われた変更は、変更パッケージの再同期コマンドでインテグレーション ブランチにマージされ、そのブランチでテストされてからメイン トランクにマージされます。新たに導入されたインテグレーション コードがメイン トランクでリリースされると、最新のメイン トランク (運用) チェックポイントからアクティブなプロジェクト ブランチがすべて除外され、再作成されます。これにより、すべてのアクティブなプロジェクト ブランチが最新の運用リリースと強制的に同期されます。

プロジェクトに基づいたブランチ作成モデルでは、ブランチの作成対象を、同時にまたは並行して実行される開発プロジェクトに限定することをお勧めします。フィーチャー、拡張機能、不具合、またはタスクの各レベルでブランチを作成することはお勧めできません。