午前2時の「Git Status」という悪夢
想像してみてください。システムに重大な障害が発生し、すぐにホットフィックスを当てる必要があります。git cloneを叩くと「残り1時間」という表示.待ちくたびれた末にブランチを確認しようとgit statusを打つと、数ファイルの変更を表示するためだけに画面がさらに30秒フリーズする……。
私はかつて、200万以上のファイルを含む30GB近い勘定系システムのレポジトリを管理していた際、この苦しみを味わいました。当時のGit操作は忍耐力のテストのようでした。標準のGitは物理的な限界に達していたのです。その解決策として行き着いたのが、Microsoftが開発したオープンソースツール（現在はGit coreに統合済み）のScalarです。これは「超」大規模プロジェクト専用の特効薬です。
クイックスタート：5分で高速化
数GB規模のレポジトリURLを前にしているなら、従来のgit cloneは忘れましょう。Scalarを使います。
ステップ1：Gitのバージョンを確認する
ScalarはGitバージョン2.38以上を必要とします。最適化機能は新しいバージョンに集約されているため、この手順は飛ばさないでください。
git --version
# 2.38より古い場合は、git-scm.comでアップデートしてくださいステップ2：Scalarでレポジトリをクローンする
git cloneの代わりに、以下のコマンドを使用します：
scalar clone https://github.com/your-org/your-giant-repo.gitステップ3：違いを実感する
クローン後、Scalarは自動的にsparse-checkoutとバックグラウンドでの最適化設定を有効にします。git statusのレスポンスがほぼ瞬時になることに気づくはずです。
なぜプロジェクトが肥大化するとGitは失速するのか？
Scalarがなぜ効果的なのかを知るために、Gitの弱点を見てみましょう。デフォルトでは、Gitは各ローカルマシンに全履歴と全ファイルを保持するように設計されています。レポジトリが5GBを超えたり、ファイル数が10万件を超えたりすると、以下のような問題が発生します。
- インデックスの肥大化: Gitは変更箇所を探すために、数百万ものファイルをスキャンし続けなければなりません。
- 帯域幅の枯渇: 二度と触ることのない5年前の古いファイルをダウンロードするために、何時間も費やすことになります。
- リソースの浪費: 差分比較（diff）やマージ（merge）コマンドが、マシンのRAMを食い尽くす可能性があります。
ScalarはGitを置き換えるものではありません。3つの核となるメカニズムを通じてGitエンジンをよりスマートに動かす、ターボチャージャーのような存在です。
Scalarが超巨大レポジトリを処理するための「3つの武器」
1. Sparse-checkout（必要なものだけを取得）
エンタープライズプロジェクトにおいて、すべてのモジュールのコードを同時に修正することは稀です。Scalarはデフォルトでルートディレクトリのファイルのみをチェックアウトします。特定のフォルダでの作業が必要になった時に初めて、Gitにそのフォルダのダウンロードを要求します。これにより、ディスク使用量を20GBから数百MBにまで削減できます。
2. ファイルシステムモニター (FSMonitor)
通常、Gitは変更されたファイルを探すためにディスクを自らスキャンします。Windowsではこれが非常に低速です。ScalarはFSMonitorを有効にし、OSからの通知を「リッスン」します。ファイルが変更されるとOSが即座にGitに通知するため、git statusは手動でファイルを走査する必要がなくなります。
3. バックグラウンドメンテナンス（バックグラウンド保守）
これは生産性を守るための機能です。git gcによるゴミ掃除をユーザーに待たせる代わりに、ScalarはこれらのタスクをOSのスケジュールに自動登録します。1時間に1回、インデックスを静かに最適化し、新しいデータをプリフェッチ（事前取得）します。あなたが作業を始める頃には、データはすでに準備万端です。
応用テクニック：Scalarによるワークフローの習得
クローン後、sparse-checkoutの影響でファイルが足りないと感じても心配いりません。以下のコマンドで必要なフォルダを取得できます。
# レポジトリのsrcディレクトリに移動
cd your-giant-repo/src
# 作業したいフォルダを指定
git sparse-checkout set folder-a folder-b/sub-folderScalarで最適化されているレポジトリの一覧を確認する場合：
scalar listレポジトリを通常の管理状態に戻したい場合：
scalar unregister100万行規模のプロジェクトからの実戦経験
15人のチームにScalarを導入した際、環境構築の時間を45分から8分に短縮できました。ただし、いくつか注意点があります。
- 「src」ディレクトリ構造: Scalarは
srcという名前の外包フォルダを作成します。コードはrepo-name/src配下に置かれるため、パスの不整合を防ぐためにCI/CDスクリプトを更新してください。 - IDEのサポート: VS CodeやIntelliJ IDEAの最新バージョンはこの構造を適切に認識します。古いツールでは、コードが存在していてもファイル欠落の警告が出ることがあります。
- お馴染みのGitコマンド: add、commit、pushはこれまで通り使えます。Scalarはインフラ層に介入して高速化しているだけです。
最後に
Gitが遅いからといって、すぐにレポジトリを細分化（マイクロレポジトリ化）しようとしないでください。細分化は依存関係管理の複雑化という代償を伴います。代わりにScalarを試してみてください。これは最も低コストでありながら、チームの生産性に即座に効果を発揮する解決策です。ターミナルを眺めて待つ時間ではなく、コードを書く時間に集中しましょう。
