大規模なリポジトリを扱う
Git は広く採用されており、推奨されている優れたバージョン管理システムですが、大規模なリポジトリを操作するとき、いくつかの事項を懸念し、対処する必要があります。
分散バージョン管理システムにリポジトリのローカル コピーを持つことは実用的ですが、大規模なリポジトリが配置されている場合は、重要な問題になるおそれがあります。
たとえば、Microsoft は、300 GB を超えるデータを含むリポジトリを内部システムから Git に移行するときに、この問題を検出しました。
リポジトリが大きくなる理由
大規模なリポジトリには、主に次の 2 つの原因があります。
- 長い履歴
- 大きなバイナリ ファイル
シャロー クローン
開発者がローカル リポジトリで利用可能なすべての履歴を必要としない場合は、シャロー クローンを実装することをお勧めします。
ローカル開発システム上のスペースと同期に必要な時間の両方が節約されます。
実行するクローンの深さを指定できます。
git clone --depth [depth] [clone-url]
ブランチをフィルター処理するか、1 つのブランチのみをクローンして、クローンを減らすこともできます。
VFS for Git
VFS for Git は、大規模なリポジトリで役立ちます。 これには Git LFS クライアントが必要です。
通常の Git コマンドは影響を受けませんが、Git LFS は標準のファイル システムと連携して、サーバーからのファイルが必要なときに、必要なファイルをバックグラウンドでダウンロードします。
Git LFS クライアントはオープンソースとしてリリースされました。 このプロトコルは、REST エンドポイントに似た 4 つのエンドポイントを持つ、わかりやすいプロトコルです。
大規模なリポジトリの詳細については、大きなファイルを扱う方法に関するページと、「Virtual File System for Git: Git をエンタープライズ規模で有効にする」を参照してください。
スカラー
Scalar は Windows と macOS で使用できる .NET Core アプリケーションです。 Git 用のツールと拡張機能を使用すると、非常に大規模なリポジトリで Git コマンドのパフォーマンスを最大化できます。 Microsoft では、Windows リポジトリと Office リポジトリにこれを使用します。
Azure Repos でリポジトリをホストする場合、GVFS プロトコルを利用してリポジトリを複製できます。
これは次のような高度な Git 機能を有効にすることで実現されます。
- 部分的複製: すべての Git オブジェクトをすぐにダウンロードしないことで作業リポジトリを取得する時間を短縮します。
- バックグラウンド プリフェッチ: 1 時間ごとにすべてのリモートから Git オブジェクトをダウンロードし、フォアグラウンドの Git フェッチ呼び出しの時間を短縮します。
- スパースチェックアウト: 作業ディレクトリのサイズを制限します。
- ファイル システム モニター: 最近変更されたファイルを追跡し、Git で作業ツリー全体をスキャンする必要性をなくします。
- コミットグラフ: コマンドの進行と到達可能性計算を高速化し、git log などのコマンドをスピードアップします。
- マルチパックインデックス: 多数のパック ファイルを対象にオブジェクトを高速で検索します。
- 増分再パック: multi-pack-index を利用して同時実行コマンドを中断させることなく、パック済みの Git データを再パックし、パック ファイルを少なくします。
注意
Microsoft では、新しい Git バージョンがリリースされたとき、Scalar で自動的に構成される機能の一覧を更新します。
詳細については、次を参照してください。