次の方法で共有

TFVC から Git にリポジトリをインポートして移行する

Azure DevOps Services |Azure DevOps Server 2022 |Azure DevOps Server 2020

既存の Team Foundation バージョン管理 (TFVC) リポジトリから同じ組織内の新しい Git リポジトリにコードを移行できます。 Git への移行は、大規模な TFVC リポジトリとチームに関連するプロセスです。 TFVC などの一元化されたバージョン管理システムは、基本的な方法で Git とは動作が異なります。 スイッチには、新しいコマンドを学習するよりもはるかに多くの作業が含まれます。 これは、慎重な計画を必要とする破壊的変更です。 次のことを考慮する必要があります。

  • ツールとプロセスの変更
  • バイナリと実行可能ファイルの削除
  • チームのトレーニング

[前提条件]

カテゴリ Requirements
プロジェクトへのアクセス権 プロジェクトのメンバー。
アクセス許可 - プライベート プロジェクトのコードを表示する: 少なくとも Basic アクセス。
- プライベート プロジェクトのコードを複製または投稿する: 共同作成者 セキュリティ グループのメンバー、またはプロジェクト内の対応するアクセス許可。
- ブランチまたはリポジトリのアクセス許可を設定する: ブランチまたはリポジトリの アクセス許可を管理 します。
- 既定のブランチを変更する: リポジトリ のポリシー のアクセス許可を編集します。
- リポジトリをインポートする: プロジェクト管理者 セキュリティ グループのメンバーまたは Git プロジェクト レベルの [リポジトリ の作成 ] アクセス許可が [許可] に設定されています。 詳細については、「Git リポジトリのアクセス許可を設定する」を参照してください。
サービス リポジトリが有効になっています。
ツール Optional. az repos コマンドを使用する: Azure DevOps CLI。

注

パブリック プロジェクトでは、 利害関係者 アクセス権を持つユーザーは、コードの表示、複製、投稿など、Azure Repos へのフル アクセス権を持ちます。

カテゴリ Requirements
プロジェクトへのアクセス権 プロジェクトのメンバー。
アクセス許可 - コードの表示: 少なくとも 基本 アクセス。
- コードの複製または投稿: 共同作成者 セキュリティ グループのメンバー、またはプロジェクト内の対応するアクセス許可。
サービス リポジトリが有効になっています。

移行を開始する前に、 Git への一元的なバージョン管理 と TFVC から Git への移行に関する セクションを読むことを強くお勧めします。

インポート エクスペリエンスは、小規模でシンプルな TFVC リポジトリに最適です。 また、Git への 一元的なバージョン管理 と TFVC から Git への移行 に関するセクションで説明されているように、既にクリーンなリポジトリにも適しています。 これらのセクションでは、より高度な TFVC リポジトリ構成用の他のツールも推奨されます。

Important

TFVC と Git のバージョン管理履歴の格納方法の違いにより、履歴を移行しないことをお勧めします。これは、Windows やその他の製品を一元化されたバージョン管理から Git に移行したときに Microsoft が取ったアプローチです。

リポジトリをインポートする

  1. [リポジトリ]、[ファイル] の順に選択します。

    ブランチを表示する

  2. リポジトリのドロップダウンから、[ リポジトリのインポート] を選択します。

    [リポジトリのインポート] オプション

  3. [ソースの種類] ドロップダウンから TFVC を選択する

  4. Git リポジトリにインポートするリポジトリ/ブランチ/フォルダーへのパスを入力します。 たとえば、$/Fabrikam/FabrikamWebsite のように指定します。

  5. TFVC リポジトリから履歴を移行する場合は、[ 移行履歴 ] を選択し、日数を選択します。 最新の変更セットから最大 180 日間の履歴を移行できます。 TFVC リポジトリへのリンクは、Git に移行された最初の変更セットのコミット メッセージに追加されます。これにより、必要なときに古い履歴を簡単に見つけることができます。

  6. 新しい Git リポジトリに名前を付けて、[インポート] を選択 します。 インポートのサイズによっては、Git リポジトリの準備が数分で完了します。

    [リポジトリのインポート] ダイアログ

トラブルシューティング

このエクスペリエンスは、移行用に準備された小規模でシンプルな TFVC リポジトリまたはリポジトリ用に最適化されています。 これは、いくつかの制限があることを意味します。

  1. これは、ルートまたはブランチの内容のみを移行します。 たとえば、 $/Fabrikam に 1 つのブランチと 1 つのフォルダーがある TFVC プロジェクトがある場合、 $/Fabrikam をインポートするパスはフォルダーをインポートし、 $/Fabrikam/<branch> はブランチのみをインポートします。
  2. インポートされたリポジトリと関連する履歴 (インポートされた場合) は、サイズが 1 GB を超えることはできません。
  3. 最大 180 日間の履歴をインポートできます。

前述の情報のいずれかがインポートの妨げになっている場合は、 Git-TFS などの外部ツールを試して、ホワイトペーパー ( Git への一元的なバージョン管理 )、 TFVC から Git への移行 に関する次のセクションを参照することをお勧めします。

Important

Microsoft 製品、サービス、プラットフォームでの Git-TFS などの外部ツールの使用は、完全にユーザーの責任です。 Microsoft は、このような Microsoft 以外の拡張機能の機能、信頼性、またはセキュリティを保証、サポート、または保証しません。

TFVC から Git への移行

一元化されたバージョン管理システムから Git にソース コードを移行する前に、2 つの違いを理解し、 移行の準備をします。

Requirements

移行を容易にするために、この記事の前のセクションの リポジトリのインポート 手順に従う前に、多くの要件があります。

  • 1 つのブランチのみを移行します。 移行を計画するときは、Git の新しい分岐戦略を選択します。 メイン ブランチのみを移行すると、 Gitflow や GitHub Flow などのトピック ブランチ ベースのワークフローがサポートされます。
  • 次のように、最新バージョンのソース コードのみをインポートして、ヒントの移行を行います。 TFVC の履歴が単純な場合は、チームが Git からのみ作業できるように、一部の履歴 (最大 180 日) を移行することを選択できます。 詳細については、「 Git への移行を計画する」を参照してください。
  • イメージ、科学的データ セット、ゲーム モデルなどのバイナリアセットをリポジトリから除外します。 これらの資産では、インポート ツールが構成しない Git LFS (Large File Storage) 拡張機能を使用する必要があります。
  • インポートしたリポジトリのサイズを 1 GB 未満にしてください。

リポジトリがこれらの要件を満たしていない場合は、代わりに Git-TFS ツール を使用して移行を行います。

Important

Microsoft 製品、サービス、プラットフォームでの Git-TFS などの外部ツールの使用は、完全にユーザーの責任です。 Microsoft は、このような Microsoft 以外の拡張機能の機能、信頼性、またはセキュリティを保証、サポート、または保証しません。

Migrate

TFVC から移行するプロセスは簡単です。

  1. ローカル ディスク上の TFVC から最新バージョンのブランチを確認します。
  2. リポジトリからバイナリとビルド ツールを削除し、NuGet などのパッケージ管理システムを設定します。
  3. バージョン コントロール固有の構成 ディレクティブを変換します。 たとえば、 .tfignore ファイルを .gitignoreに変換し、 .tpattributes ファイルを .gitattributesに変換します。
  4. 変更をチェックインし、Git への移行を実行します 。

手順 1 から 3 は省略可能です。 リポジトリにバイナリがなく、 .gitignore または .gitattributesを設定する必要がない場合は、変更のチェックインに直接進 み、移行手順を実行 できます。

最新バージョンを確認する

新しいワークスペースを作成し、Git に移行するサーバー ディレクトリの作業フォルダーをマップします。 このアクションでは、完全な作業フォルダー マッピングは必要ありません。 リポジトリから削除するバイナリを含むフォルダーと、 .tfignoreなどのバージョン 管理システム固有の構成ファイルを含むフォルダーのみをマップします。

マッピングが設定されたら、フォルダーをローカルに取得します。

tf get /version:T /recursive

バイナリとビルド ツールを削除する

Git では、すべての開発者に履歴内のすべてのファイルのコピーを提供することで、変更されたファイルの履歴が格納されるため、バイナリ ファイルをリポジトリに直接チェックインすると、リポジトリが急速に拡大し、パフォーマンスの問題につながる可能性があります。

ビルド ツールやライブラリなどの依存関係の場合は、NuGet などのバージョン管理をサポートする パッケージ ソリューション を採用します。 多くのオープン ソース ツールとライブラリは NuGet ギャラリーで既に使用できますが、独自の依存関係については、新しい NuGet パッケージを作成します。

依存関係が NuGet に移動されたら、それらを .gitignore に追加して、それらの依存関係が Git リポジトリに含まれていないことを確認します。

バージョン コントロール固有の構成を変換する

Team Foundation Version Control には .tfignore ファイルが用意されており、これにより、特定のファイルが TFVC リポジトリに追加されないようにします。 .tfignore ファイルは、ビルド出力などの自動生成されたファイルに使用して、誤ってチェックインされないようにすることができます。

プロジェクトがこの動作に依存している場合は、 .tfignore ファイルを .gitignore ファイルに変換します。

クロスプラットフォーム TFVC クライアントでは、ローカル ディスクにファイルを配置する方法やリポジトリにチェックインする方法を制御する .tpattributes ファイルもサポートされます。 .tpattributes ファイルが使用中の場合は、.gitattributes ファイルに変換します。

変更をチェックインして移行を実行する

バイナリの削除、パッケージ管理への移行、またはバージョン 管理固有の構成の変換を行う変更をチェックインします。 TFVC でこの最終的な変更を行うと、 インポートを行うことができます。

高度な移行

Git-TFS ツールは TFVS と Git の間の双方向ブリッジであり、それを使用して移行を実行できます。 Git-TFS は、インポート ツールがサポートする 180 日を超える完全な履歴を含む移行に適しています。 または、Git-TFS を使用して、複数のブランチとマージ リレーションシップを含む移行を試みることもできます。

Git-TFS を使用して移行を試みる前に、TFVC と Git ストアの履歴の基本的な違いに注意してください。

  • Git は履歴をリポジトリのスナップショットとして時間内に格納し、TFVC はファイルで発生した個別の操作を記録します。 TFVC の変更の種類 (名前の変更、削除の取り消し、ロールバックなど) は、Git では表現できません。 ファイル A の名前がファイル Bに変更されたのではなく、そのファイル A が削除され、ファイル B が同じコミットに追加されたことのみが追跡されます。
  • Git には TFVC ラベルの直接的な類似体がありません。 ラベルには、特定のバージョンの任意の数のファイルを含めることができます。また、異なるバージョンのファイルを反映することもできます。 概念的には似ていますが、Git タグは一度にリポジトリ全体のスナップショットを指します。 プロジェクトが TFVC ラベルに依存して配信された内容を知っている場合、Git タグはこの情報を提供しない可能性があります。
  • TFVC のマージは、リポジトリ全体ではなく、ファイル レベルで行われます。 1 つのブランチから別のブランチにマージできるのは、変更されたファイルのサブセットだけです。 その後、残りの変更されたファイルは、後続の変更セットにマージされる可能性があります。 Git では、マージはリポジトリ全体に影響し、個々の変更の両方のセットをマージと見なすことはできません。

これらの違いがあるため、履歴を表示するには、ヒントの移行を行い、TFVC リポジトリをオンラインのままにすることをお勧めしますが、読み取り専用です。

Git-TFS を使用して高度な移行を試みる場合は、 履歴を含む単一のブランチを複製 する方法、または マージ履歴を含むすべてのブランチを複製する方法を参照してください。

Important

Microsoft 製品、サービス、プラットフォームでの Git-TFS などの外部ツールの使用は、完全にユーザーの責任です。 Microsoft は、このような Microsoft 以外の拡張機能の機能、信頼性、またはセキュリティを保証、サポート、または保証しません。

ワークフローを更新する

一元化されたバージョン管理システムから Git への移行は、単なるコードの移行だけではありません。 チームは、Git が既存のバージョン管理システムとどのように異なるか、およびこれらの違いが日常の作業にどのように影響するかを理解するためのトレーニングが必要です。

一元化されたバージョン管理から Git に移行する方法の詳細について説明します。