一元化されたバージョン管理からチームを Git に移行するには、単に新しいコマンドを学習する以上のものが必要です。 分散開発をサポートするために、Git では、一元化されたバージョン管理システムとは異なる方法でファイル履歴とブランチ情報が格納されます。 一元化されたバージョン管理システムから Git への移行を正常に計画して実装するには、これらの基本的な違いを理解する必要があります。
Microsoft は、多くの社内チームとお客様を、集中管理されたバージョン管理システムから Git に移行する手助けをしてきました。 このエクスペリエンスでは、一貫して成功するプラクティスに基づいて、次のガイダンスが生成されています。
移行を成功するための手順
移行を成功させるには、チームは次の作業を行う必要があります。
- 現在のツールとプロセスを評価します。
- Git 分岐戦略を選択します。
- 履歴を移行するかどうかと移行方法を決定します。
- 以前のバージョンの管理システムを維持します。
- ソース管理からバイナリ ファイル、実行可能ファイル、およびツールを削除します。
- Git の概念とプラクティスでチームをトレーニングします。
- Git への移行をテストします。
現在のツールとプロセスを評価する
バージョン管理システムを変更すると、新しいツールとプラクティスによって開発ワークフローが自然に中断されます。 この中断は、DevOps プロセスの他の側面を改善する機会となる可能性があります。
Teams は、新しいシステムに移行する場合に、次のプラクティスを採用することを検討する必要があります。
継続的インテグレーション (CI)。すべてのチェックインによって ビルドとテストの成功がトリガーされます。 CI は、早期に欠陥を特定するのに役立ち、プロジェクトに強力なセーフティ ネットを提供します。
コードのチェックイン前にはコードレビューが必要です。 Git 分岐モデルでは、 pull request コード レビューが開発プロセスの一部です。 コード レビューは CI ワークフローを補完します。
デプロイ プロセスを自動化するための継続的デリバリー (CD)。 バージョン管理ツールを変更するにはデプロイ プロセスの変更が必要であるため、移行は最新のリリース パイプラインを導入するのに適したタイミングです。
Git 分岐戦略を選択する
コードを移行する前に、チームは 分岐戦略を選択する必要があります。
Git では、有効期間の短い トピック ブランチを使用すると、開発者はメイン ブランチの近くで作業し、迅速に統合できるため、マージの問題を回避できます。 2 つの一般的なトピックブランチ戦略は、 GitFlow とより単純なバリエーションである GitHub Flow です。
Git は、統合が困難になるまでマージを遅らせる傾向がある、長期間の分離された機能ブランチを推奨しません。 機能フラグなどの最新の CD 手法を使用することで、チームはコードをメイン ブランチに迅速に統合できますが、完了するまで進行中の機能はユーザーに表示されません。
現在有効期間の長い機能ブランチ戦略を使用しているチームは、Git に移行する前に機能フラグを採用できます。 機能フラグを使用すると、移行するブランチの数が最小限に抑えられ、移行が簡略化されます。 機能ブランチと機能フラグのどちらを使用する場合でも、チームは従来のブランチと新しい Git ブランチの間のマッピングを文書化する必要があるため、誰もが新しい作業をコミットする場所を理解できます。
履歴を移行するかどうかを決定する
Teams は、既存のソース コード履歴を Git に移行したくなる可能性があります。 いくつかのツールは、すべてのブランチの完全な履歴を一元化されたツールから Git に移行すると主張しています。 Git コミットは、以前のバージョン管理ツールが使用した変更セットまたはチェックイン モデルに比較的適切にマップされているようです。
ただし、このマッピングにはいくつかの重大な制限があります。
ほとんどの一元化されたバージョン管理システムでは、ブランチはリポジトリ内のフォルダーとして存在します。 たとえば、メイン ブランチは /trunk という名前のフォルダーで、他のブランチは /branch/one や /branch/two などのフォルダーです。 Git リポジトリでは、ブランチにはリポジトリ全体が含まれているため、1 対 1 の翻訳は困難です。
一部のバージョン 管理システムでは、 タグ または ラベル は、異なるバージョンのファイルであっても、ツリー内のさまざまなファイルを含むことができるコレクションです。 Git では、 タグ は特定の時点におけるリポジトリ全体のスナップショットです。 タグは、リポジトリのサブセットを表したり、異なるバージョンのファイルを結合したりすることはできません。
ほとんどのバージョン管理システムには、名前の変更、削除の取り消し、ロールバックなどのきめ細かい変更の種類など、バージョン間のファイルの変更方法に関する詳細が格納されます。 Git では、バージョンがリポジトリ全体のスナップショットとして格納され、ファイルの変更方法に関するメタデータは使用できません。
これらの違いは、履歴の完全な移行がせいぜい損失し、誤解を招く可能性があることを意味します。 損失、関連する労力、履歴を使用する相対的な希少性を考えると、ほとんどのチームが履歴をインポートしないようにすることをお勧めします。 代わりに、チームは ヒントの移行を行い、最新のブランチ バージョンのスナップショットのみを Git に取り込む必要があります。 ほとんどのチームでは、プロセスの改善など、投資収益率が高い移行の領域に時間を費やすのが最適です。
古いバージョン管理システムを維持する
移行中および移行後も、開発者は以前のバージョン管理履歴にアクセスする必要がある場合があります。 以前のバージョンコントロールの履歴は時間の経過とともに関連性が低くなりますが、それを参照できることが重要です。 厳しく規制された環境には、バージョン管理履歴の特定の法的要件と監査要件がある場合があります。
特に、チップの移行のみを行うチームの場合は、以前のシステムを無期限に維持することを強くお勧めします。 移行後、古いバージョン管理システムを読み取り専用に設定します。
大規模な開発チームや規制された環境がある場合には、古いバージョン管理システムを指す パンくずリスト を Git に配置することができます。 簡単な例としては、古いバージョン管理サーバーの URL を指しているテキストファイルが、Git リポジトリのルートで最初のコミットとして、先端の移行前に追加されている場合があります。 多数のブランチが移行される場合は、各ブランチのテキスト ファイルで、ブランチが古いシステムから移行された方法を説明する必要があります。 パンくずリストは、移行後にプロジェクトに着手し、従来のバージョン管理システムに慣れていない開発者にとっても役立ちます。
バイナリ ファイルとツールを削除する
Git のストレージ モデルは、圧縮性が高くコンパクトなテキスト ファイルとソース コードのバージョン管理用に最適化されています。 通常、バイナリ ファイルは大きく、リポジトリに追加されると、リポジトリの履歴と今後のすべてのクローンに残ります。 Git が履歴を格納する方法により、開発者は、特に非常に大きいバイナリや頻繁に変更されるバイナリをリポジトリに追加しないようにする必要があります。 Git への移行は、コードベースからこれらのバイナリを削除する機会です。
また、ライブラリ、ツール、ビルド出力をリポジトリから除外することもお勧めします。 代わりに、NuGet などのパッケージ管理システムを使用して依存関係を管理します。
アイコンやアートワークなどのアセットは、特定のバージョンのソース コードに合わせる必要がある場合があります。 アイコンなどの変更頻度の低い小さなアセットは履歴を肥大化させず、リポジトリに直接含めることができます。 大きな資産または頻繁に変更される資産を格納するには、Git Large File Storage (LFS) 拡張機能を使用します。 GitHub での大きなファイルの管理の詳細については、「 大きなファイルの管理」を参照してください。 Azure Repos については、 Git での大きなファイルの管理と格納に関するページを参照してください。
トレーニングを提供する
Git への移行における最大の課題の 1 つは、開発者が Git ストアの変更方法と、コミットによって開発履歴がどのように形成されるかを理解することです。 古いコマンドを Git コマンドにマップするチート シートを準備するだけでは不十分です。 開発者は、一元化された線形モデルの観点からバージョン管理履歴について考えるのをやめ、Git の履歴モデルとコミット グラフを理解する必要があります。
ユーザーはさまざまな方法で学習するので、いくつかの種類のトレーニング資料を提供する必要があります。 専門家のインストラクターによるラボベースのライブトレーニングは、一部の人々に適しています。 Pro Git ブックは、無料のオンラインで入手できる優れた出発点です。
以下の無料のハンズオン トレーニング コースを利用できます。
- Git ラーニング パスを使用したバージョン管理の概要。
- Azure Repos での Git を始めるクイックスタート。
- GitHub の Git と GitHub の学習リソース。
組織は、チームの Git エキスパートを特定し、他のユーザーを支援できるように支援し、他のチーム メンバーに質問を促す作業を行う必要があります。
移行をテストする
チームがプロセスを更新し、コードを分析し、メンバーをトレーニングしたら、ソース コードを移行します。 ヒントの移行や履歴の移行のいずれを行う場合でも、テスト リポジトリに 1 つ以上のテスト移行を行う必要があります。 最終的な移行を行う前に、次のことを確認してください。
- すべてのコード ファイルが移行されます。
- すべてのブランチを使用できます。
- リポジトリに迷子のバイナリはありません。
- ユーザーはフェッチとプッシュを行うための適切なアクセス許可を持っています。
- ビルドが成功し、すべてのテストが成功します。
コードを移行する
勤務時間外に最終的な移行を行います。理想的には、自然なダウンタイムがある場合のマイルストーン間です。 スプリントの終了時に移行すると、開発者が作業を完了しようとしている間に問題が発生する可能性があります。 誰もチェックインする必要がないように、週末に移行してみてください。
古いバージョン管理システムから Git へのしっかりとしたカットオーバーを計画します。 複数のシステムを並列で運用しようとすると、開発者はチェックインの場所や方法がわからない可能性があります。 混乱を避けるために、古いバージョン管理システムを読み取り専用に設定します。 このセーフガードがないと、中間変更を含む 2 つ目の移行が必要になる場合があります。
実際の移行プロセスは、移行するシステムによって異なります。 Team Foundation バージョン管理からの移行の詳細については、「 TFVC から Git への移行」を参照してください。
移行チェックリスト
チーム ワークフロー:
- ビルドの実行方法を決定します。
- テストを実行するタイミングを決定します。
- リリース管理プロセスを開発します。
- コード レビューをプル要求に移動します。
分岐戦略:
- Git 分岐戦略を選択します。
- 分岐戦略、その戦略が選ばれた理由、そして過去のブランチがどのようにマッピングされるかを文書化します。
History:
- レガシ バージョン管理を実行し続ける期間を決定します。
- 移行する必要があるブランチを特定します。
- 必要に応じて、エンジニアがレガシーシステムに戻れるように、パンくずリストを作成してください。
バイナリとツール:
- リポジトリから削除するバイナリと不明なファイルを特定します。
- 大きなファイルを扱うためのアプローチを決定します。例えば、Git-LFSがあります。
- NuGet などのツールとライブラリを提供するためのアプローチを決定します。
訓練：
- トレーニング資料を特定します。
- トレーニング イベント、書かれた資料、ビデオを計画します。
- ローカル Git エキスパートとして機能するチームのメンバーを特定します。
コードの移行:
- 移行がスムーズに行われるように、複数のテスト実行を実行します。
- カットオーバー時間を特定し、それを関係者に伝達します。
- 新しい Git リポジトリを作成します。
- 古いシステムを読み取り専用に設定します。
- 最初にメイン ブランチを移行し、次に他の必要なブランチを移行します。