一元化されたバージョン コントロールから Git に移行する

  • [アーティクル]

チームを一元的なバージョン管理から Git に移行するには、新しいコマンドを学習するだけでは不十分です。 分散開発をサポートするために、Git は集中バージョン管理システムとは異なる方法でファイル履歴とブランチ情報を保存します。 集中バージョン管理システムから Git への移行を計画して実装するには、これらの基本的な違いを理解する必要があります。

Microsoft は、多くの社内チームや顧客を集中バージョン管理システムから Git へ移行するのを支援してきました。 この経験により、一貫して成功する実践に基づいた次のガイダンスが生まれました。

移行を成功させるための手順

移行を成功させるために、チームは次のことを行う必要があります。

  • 現在のツールとプロセスを評価する。
  • Git ブランチ戦略を選択します。
  • 履歴を移行するかどうか、またその方法を決定します。
  • 以前のバージョン管理システムを維持します。
  • バイナリ ファイル、実行可能ファイル、およびツールをソース管理から削除します。
  • Git の概念と実践についてチームをトレーニングします。
  • Git への移行をテストします。

現在のツールとプロセスを評価する

バージョン管理システムを変更すると、当然のことながら、新しいツールや手法による開発ワークフローが中断されます。 この混乱は、DevOps プロセスの他の側面を改善する機会となる可能性があります。

チームは、新しいシステムに移行する際に、次のプラクティスの採用を検討する必要があります。

  • 継続的インテグレーション (CI)。チェックインごとにビルドとテストのパスがトリガーされます。 CI は欠陥を早期に特定するのに役立ち、プロジェクトに強力なセーフティ ネットを提供します。

  • コードをチェックインする前にコード レビューが必要。 Git ブランチング モデルでは、プル リクエスト コード レビューは開発プロセスの一部です。 コード レビューは CI ワークフローを補完します。

  • 継続的デリバリー (CD) により、導入プロセスを自動化します。 バージョン管理ツールを変更するには展開プロセスの変更が必要となるため、移行は最新のリリース パイプラインを採用する良い機会です。

Git ブランチ戦略を選択します

コードを移行する前に、チームは分岐戦略を選択する必要があります。

Git では、有効期間が短い topic ブランチにより、開発者はメイン ブランチの近くで作業し、迅速に統合して、マージの問題を回避できます。 2 つの一般的なトピック ブランチ戦略は、GitFlow と、より単純なバリエーションである GitHub Flow です。

Git は、統合が困難になるまでマージが遅れる傾向にある、存続期間の長い孤立した機能ブランチを抑制します。 機能フラグなどの最新の CD テクニックを使用することで、チームはコードをメイン ブランチに迅速に統合しながら、完成するまで進行中の機能をユーザーから隠し続けることができます。

現在、長期存続する機能ブランチ戦略を使用しているチームは、Git に移行する前に機能フラグを採用できます。 機能フラグを使用すると、移行するブランチの数が最小限に抑えられ、移行が簡素化されます。 フィーチャー ブランチを使用するかフィーチャー フラグを使用するかに関係なく、チームはレガシー ブランチと新しい Git ブランチの間のマッピングを文書化して、新しい作業をどこにコミットするかを全員が理解できるようにする必要があります。

履歴を移行するかどうかを決定する

チームは、既存のソース コード履歴を Git に移行したくなるかもしれません。 いくつかのツールは、すべてのブランチの完全な履歴を一元化されたツールから Git に移行すると主張しています。 Git コミットは、以前のバージョン管理ツールが使用していたチェンジセットまたはチェックイン モデルに比較的よくマッピングされているようです。

ただし、このマッピングには重大な制限がいくつかあります。

  • ほとんどの集中型バージョン管理システムでは、ブランチはリポジトリ内のフォルダーとして存在します。 たとえば、メイン ブランチは/trunk という名前のフォルダーであり、他のブランチは /branch/one や /branch/two などのフォルダーです。 Git リポジトリでは、ブランチにリポジトリ全体が含まれるため、1 対 1 の翻訳は困難です。

  • 一部のバージョン管理システムでは、タグ または ラベル は、ツリー内のさまざまなファイル (異なるバージョンのファイルも含む) を含むことができるコレクションです。 Git では、タグ は、特定の時点でのリポジトリ全体のスナップショットです。 タグはリポジトリのサブセットを表したり、異なるバージョンのファイルを結合したりすることはできません。

  • ほとんどのバージョン管理システムは、名前変更、削除取り消し、ロールバックなどのきめ細かい変更タイプを含め、バージョン間のファイルの変更方法に関する詳細を保存します。 Git はバージョンをリポジトリ全体のスナップショットとして保存するため、ファイルの変更方法に関するメタデータは利用できません。

これらの違いは、履歴全体の移行は良くても損失が大きく、誤解を招く可能性があることを意味します。 履歴を使用することの損失性、それに伴う労力、および相対的な希少性を考慮すると、ほとんどのチームは履歴のインポートを避けることをお勧めします。 代わりに、チームはヒントの移行を実行して、最新のブランチ バージョンのスナップショットのみを Git に取り込む必要があります。 ほとんどのチームにとって、プロセスの改善など、投資収益率がより高い移行領域に時間を費やすのが最適です。

古いバージョン管理システムを維持する

移行中および移行後も、開発者は以前のバージョン管理履歴にアクセスする必要がある場合があります。 以前のバージョン管理履歴は時間の経過とともに重要性が低くなりますが、参照できることは依然として重要です。 高度に規制された環境では、バージョン管理履歴に関して特定の法的要件や監査要件が存在する場合があります。

特にチップの移行のみを行うチームの場合は、以前のシステムを無期限に維持することを強くお勧めします。 移行後、古いバージョン管理システムを読み取り専用に設定します。

大規模な開発チームや規制された環境では、古いバージョン管理システムを参照する ブレッドクラム を Git に配置することができます。 簡単な例は、ヒントの移行前に、Git リポジトリのルートに最初のコミットとして追加され、古いバージョン管理サーバーの URL を指すテキスト ファイルです。 多くのブランチを移行する場合は、各ブランチのテキスト ファイルで、ブランチが古いシステムからどのように移行したかを説明する必要があります。 ブレッドクラムは、移行後にプロジェクトの作業を開始し、古いバージョン管理システムに慣れていない開発者にとっても役立ちます。

バイナリ ファイルとツールを削除する

Git のストレージ モデルは、コンパクトで圧縮率の高いテキスト ファイルとソース コードのバージョン管理用に最適化されています。 バイナリ ファイルは通常大きく、リポジトリに追加されると、リポジトリ履歴と今後のすべてのクローンに残ります。 Git が履歴を保存する方法のため、開発者はリポジトリにバイナリ ファイル、特に非常に大きいバイナリや頻繁に変更されるバイナリを追加しないようにする必要があります。 Git への移行は、コードベースからこれらのバイナリを削除する機会となります。

ライブラリ、ツール、ビルド出力をリポジトリから除外することもお勧めします。 代わりに、NuGet などのパッケージ管理システムを使用して依存関係を管理します。

アイコンやアートワークなどのアセットは、ソース コードの特定のバージョンに合わせる必要がある場合があります。 アイコンのような小さくて頻繁に変更されないアセットは履歴を肥大化させず、リポジトリに直接含めることができます。 大規模なアセットまたは頻繁に変更されるアセットを保存するには、Git Large File Storage (LFS) 拡張機能を使用します。 GitHub での大きなファイルの管理の詳細については、「大きなファイルの管理」を参照してください。 Azure Repos については、「Git で大きなファイルを管理および保存する」を参照してください。

トレーニングの提供

Git への移行における最大の課題の 1 つは、Git が変更を保存する方法と、コミットが開発履歴をどのように形成するかを開発者が理解できるようにすることです。 古いコマンドを Git コマンドにマッピングするチートシートを準備するだけでは十分ではありません。 開発者は、集中型の線形モデルの観点からバージョン管理履歴について考えるのをやめ、Git の履歴モデルとコミット グラフを理解する必要があります。

学習方法は人によって異なるため、数種類のトレーニング教材を提供する必要があります。 専門のインストラクターによるライブのラボベースのトレーニングが効果がある人もいます。 Pro Git ブックは、オンラインで無料で入手できる優れた出発点です。

利用可能な無料の実践トレーニング コースには次のものがあります。

組織は、チーム内の Git 専門家を特定し、他のチームを支援できるように権限を与え、他のチーム メンバーに質問するよう奨励する必要があります。

移行をテストする

チームがプロセスを更新し、コードを分析し、メンバーをトレーニングしたら、ソース コードを移行します。 ヒントの移行を行う場合でも、履歴の移行を行う場合でも、テスト リポジトリに 1 つ以上のテスト移行を行うことが重要です。 最終的な移行を行う前に、次のことを確認してください。

  • すべてのコード ファイルが移行する。
  • すべてのブランチが利用可能
  • リポジトリにストレイバイナリがない。
  • ユーザーにフェッチとプッシュを行うための適切な権限がある。
  • ビルドは成功し、すべてのテストに合格した。

コードを移行する

最終的な移行は、勤務時間外に、理想的には自然なダウンタイムがあるマイルストーンの間で実行してください。 スプリントの終わりに移行すると、開発者が作業を完了しようとしている間に問題が発生する可能性があります。 誰もチェックインする必要がない週末に移行するようにしてください。

古いバージョン管理システムから Git への確実な切り替えを計画します。 複数のシステムを並行して運用しようとすると、開発者はどこでどのようにチェックインすればよいのか分からない可能性があります。 混乱を避けるために、古いバージョン管理システムを読み取り専用に設定します。 この保護策がなければ、暫定的な変更を含む 2 回目の移行が必要になる可能性があります。

実際の移行プロセスは、移行元のシステムによって異なります。 Team Foundation Version Control からの移行の詳細については、「TFVC から Git への移行」を参照してください。

移行チェックリスト

チームのワークフロー:

  • ビルドの実行方法を決定します。
  • テストをいつ実行するかを決定します。
  • リリース管理プロセスを開発します。
  • コードレビューをプルリクエストに移動します。

ブランチ戦略:

  • Git ブランチ戦略を選択します。
  • ブランチ戦略、それが選択された理由、および従来のブランチがどのようにマッピングされるかを文書化します。

履歴:

  • 従来のバージョン管理を実行し続ける期間を決定します。
  • 移行する必要があるブランチを特定します。
  • 必要に応じて、エンジニアがレガシー システムに戻るのに役立つパンくずリストを作成します。

バイナリとツール

  • リポジトリから削除するバイナリと相違不可能なファイルを特定します。
  • Git-LFS などの大きなファイルに対するアプローチを決定します。
  • NuGet などのツールやライブラリを提供するためのアプローチを決定します。

Training:

  • トレーニング資料を特定します。
  • トレーニング イベント、文書、ビデオを計画します。
  • ローカルの Git エキスパートとして機能するチームのメンバーを特定します。

コード移行

  • 複数のテストを実行して、移行がスムーズに完了することを確認します。
  • カットオーバー時間を特定して通知します。
  • 新規Gitリポジトリを作成する。
  • 古いシステムを読み取り専用に設定します。
  • 最初にメイン ブランチを移行し、次に他の必要なブランチを移行します。

次のステップ