作業領域をリベースするためのワークフロー (複数ストリームの UCM プロジェクトの場合のみ)

プロジェクト
図 1. 複数ストリーム環境内の作業領域をリベースするためのワークフロー
作業領域のリベース操作のワークフローは、アクティビティのデリバー操作の後、アクティビティの検索および設定の前に位置します (これにより、サイクルが再開します)。
このワークフローには、テスト手順および完了手順が含まれます。

複数ストリームのプロジェクトでは、プロジェクト マネージャーまたはプロジェクト統合担当者が、デリバーされたアクティビティを定期的にベースラインに編入します。通常、ベースラインはテストとバグ修正のサイクルを経て、十分な安定性のレベルに達します。ベースラインが安定したら、プロジェクト マネージャーはそのベースラインを推奨ベースラインに指定します。

親ストリームの推奨ベースラインに含まれるアクティビティを取り込んで自分の開発作業領域を最新の状態に保つためには、推奨ベースラインが指定されるごとに、そのベースラインに合わせて開発作業領域をリベースする必要があります。

リベース操作の利点:

作業領域の準備

リベース操作の準備をするには、開発ビューで作業を検索してチェックインします。 ビューにチェックアウトされたファイルがある場合は、リベース操作を開始できません。

リベース操作の開始

作業領域の準備が完了したら、リベース操作を開始します。最新の推奨ベースラインが提示されます。異なるベースラインを選択できますが、現在の開発ストリームのベースラインよりも古いベースラインは選択できません。

マージ

自分の開発ストリームでいずれかのバージョンを変更し、他のチーム メンバーも同じエレメントのバージョンをすでに変更してデリバー済みの場合には、デリバーされたバージョンを含むベースラインにリベースする際にそれらをマージする必要があります。

たとえば、次のようにします。

  1. アクティビティでの作業中に、開発ビューから prog.c のバージョンをチェックインします。
  2. 別の開発者が prog.c の新しいバージョンをチェックインしてデリバーします。
  3. プロジェクト マネージャーが新しいバージョンを推奨ベースラインに追加します。
  4. 開発ストリームをリベースします。 リベース操作中に、他の開発者のバージョンを自分の開発ストリームにマージする必要があります。

デリバー操作のときと同様に、競合しないすべての差分が解決されます。ベースライン内のバージョンに、自分の開発作業領域の対応するバージョンと競合する変更が含まれる場合には、競合する差分の解決方法を決定するよう要求されます。

テスト

作業領域が再構成され、必要なマージが完了したら、開発ビューでテスト ビルドを開始します。このテストにより、デリバーされていない作業が新しいベースラインのバージョンと正常に結合 (ビルド) されることを確認できます。

ビルドとテストのほかに、以下を行わなければならない場合があります。

リベース操作の完了

テスト ビルドに問題がなければ、正式にリベース操作を完了します。これにより、ストリームの状態が変更されます。

関連概念
作業領域のリベースについて
推奨ベースライン以外のベースラインへのリベースについて
作業領域がリベースされる方法
インテグレーション アクティビティとベースラインについて
単一ストリームのプロジェクトでリベースする場合の特別な考慮点
ファイルとディレクトリがマージされる方法
表示されないエレメントの処理について
関連タスク
ファイルとディレクトリのチェックイン
ファイルとディレクトリのチェックアウト
チェックアウトの検索

フィードバック