巨大なリポジトリを Git でうまく扱う方法

考えてみると、リポジトリが巨大化する主な理由は大きく 2 つあります。

• 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合
• 追跡してコードと組み合わせる必要がある巨大なバイナリ アセットが含まれている場合

... または両方が該当します。

2 つ目のタイプの問題は、既に廃止された古いバイナリ アーティファクトがまだリポジトリに保存されているため、さらに悪化することがありますが、そのためには比較的簡単な (面倒かもしれませんが) 修正があります。以下を参照してください。

各シナリオのテクニックと回避策は、補完的なものになることもあるものの、それぞれは異なるものですので、1 つずつ取り上げていきましょう。

2 つ目のタイプの巨大なリポジトリは、巨大なバイナリ アセットを持つリポジトリです。これは多数のさまざまなソフトウェア (およびソフトウェア以外の) チームが目にするものです。ゲーム チームは巨大な 3D モデルを扱い、Web 開発チームは未加工の画像アセットを追跡する必要があり、CAD チームはバイナリ成果物のステータスを操作し、追跡する必要があるかもしれません。

Git のバイナリ アセット処理能力は特に問題があるわけでも、特に優れているわけでもありません。既定では Git はバイナリ アセットについて一連のバージョンのすべてを圧縮して格納しますが、これはバージョン数が多い場合は明らかに得策ではありません。

この状況を改善するには、いくつかの基本的な手法があります。たとえば、ガベージ コレクション (‘git gc’) を実行する、または .gitattributes でバイナリ タイプを指定して delta コミットを適用するなどです。

しかし、プロジェクトのバイナリ アセットの性質を考えることが重要です。そうすることで効果的なアプローチを決定できるようになります。たとえば、考慮すべき点をいくつかご紹介します。

• ある種のメタデータ ヘッダーに限らず、大きな変更のあるバイナリ ファイルについては多くの場合 delta 圧縮は有効ではありません。したがって、余計な delta 圧縮動作がリパック時に発生することを防止するために「delta off」とすることを推奨します。
• 上記のシナリオでは、それらのファイルに対して zlib 圧縮もあまり有効ではないため、「core.compression 0」または「core.loosecompression 0」を指定して圧縮を無効にすることができます。ただし、これは圧縮が有効なすべての非バイナリ ファイルに悪影響を与える可能性のあるグローバル設定であるため、これはバイナリ アセットを別のリポジトリに分離した場合に有用と言えます。
• 「git gc」は「重複した」ルーズ・オブジェクトを 1 個のパック・ファイルに変換しますが、何らかの方法でファイルを圧縮しなければ、ここでも結果として生成されるパック・ファイルの圧縮効果は小さいと思われることに留意してください。
• 「core.bigFileThreshold」の微調整。512 MB より大きなファイルは delta 圧縮されないため (.gitattributes における設定がない場合)、この方法を試す価値はあるでしょう。

大きなファイルを定期的に扱う場合、アトラシアンが 2015 年に GitHub と共同開発した大容量ファイル サポート (LFS) を活用するのが最善の解決策かもしれません。(はい、そのとおりです。Git プロジェクトへのオープンソースによる寄与のために GitHub とチームを組んでいます。)

Git LFS は、ファイル自体をリポジトリに格納するのではなく、大きなファイルへのポインターをリポジトリ内に格納する拡張機能です。実際のファイルはリモート サーバーに保存されます。ご想像のとおり、これによりリポジトリのクローン作成にかかる時間が大幅に短縮されます。

リポジトリの履歴や取り扱うデータが大きいからというだけで、Git のすばらしい機能を諦める必要はありません。どちらの問題に対しても有用なソリューションがあります。

サブモジュール、プロジェクトの依存関係、Git LFS の詳細については、上記でリンクされている他の記事を参照してください。また、コマンドとワークフローについて復習するには、Git マイクロサイトに各種チュートリアルが揃っています。コーディングを試してみましょう。