Git の単一リポジトリ

そして、パフォーマンス テストを実施する際、Facebook が使用したテスト リポジトリは次のとおりです。

• 400 万件のコミット
• 直線的な履歴
• 約 130 万のファイル
• .git ディレクトリのサイズは約 15 GB
• インデックス ファイルのサイズは 191 MB

Git の単一リポジトリで無関係なプロジェクトを管理する場合、多くの概念上の課題があります。

まず、Git は、commit が実行されるたびにツリー全体の状態を追跡します。これは、単一のプロジェクトや関連するプロジェクトでは問題ありませんが、関連のないプロジェクトが多数含まれているリポジトリでは扱いにくくなります。簡単に言うと、ツリー内の無関係な部分でのコミットが、開発者に関連するサブツリーに影響します。この問題は、大量のコミットによってさらに顕著になり、ツリーの履歴が増加します。ブランチの先端がめまぐるしく変わるため、変更をプッシュするにはローカルで頻繁にマージまたはリベースする必要があります。

Git では、タグは特定のコミットの名前付きエイリアスで、ツリー全体を参照します。しかし、単一リポジトリのコンテキストでは、タグの有用性は低下します。考えてみてください。単一リポジトリで継続的にデプロイされる Web アプリケーションに取り組んでいる場合、バージョン管理された iOS クライアントのリリース タグにはどのような関連性がありますか?

これらの概念的な課題に加えて、単一リポジトリのセットアップに影響するパフォーマンス上の問題が数多くあります。

無関係なプロジェクトを大規模な単一のリポジトリで管理すると、コミット レベルで問題が発生する場合があります。時間が経つにつれて、コミット数が高い成長率で大幅に増えていきます (Facebook は「週に数千のコミット」と言っています)。これは特に厄介です。なぜなら、Git は有向非循環グラフ (DAG) を使ってプロジェクトの履歴を表すからです。コミット数が多いと、履歴が深まるにつれてグラフをたどるコマンドが遅くなる可能性があります。

Some examples of this include investigating a repository's history via git log or annotating changes on a file by using git blame. With git blame if your repository has a large number of commits, Git would have to walk a lot of unrelated commits in order to calculate the blame information. Other examples would be answering any kind of reachability question (e.g. is commit A reachable from commit B). Add together many unrelated modules found in a monorepo and the performance issues compound.

単一リポジトリ内に多数の ref (ブランチやタグなど) があると、多くの点でパフォーマンスに影響します。

Ref advertisements contain every ref in your monorepo. As ref advertisements are the first phase in any remote git operation, this affects operations like git clone, git fetch or git push. With a large number of refs, performance takes a hit when performing these operations. You can see the ref advertisement by using git ls-remote with a repository URL. For example, git ls-remote git://git.kernel.org/ pub/scm/linux/kernel/git/torvalds/linux.git will list all the references in the Linux Kernel repository.

If refs are loosely stored listing branches would be slow. After a git gc refs are packed in a single file and even listing over 20,000 refs is fast (~0.06 seconds).

Any operation that needs to traverse a repository's commit history and consider each ref (e.g. git branch --contains SHA1) will be slow in a monorepo. In a repository with 21708 refs, listing the refs that contain an old commit (that is reachable from almost all refs) took:

ユーザー時間 (秒): 146.44*

*これは、ページ キャッシュと基盤となるストレージ レイヤーによって異なります。

インデックスまたはディレクトリ キャッシュ (.git/index) は、リポジトリ内のすべてのファイルを追跡します。Git はこのインデックスを使用して、すべてのファイルに対して stat (1) を実行し、ファイルの変更情報とインデックスに含まれる情報を比較することで、ファイルが変更されたかどうかを判断します。

したがって、追跡されるファイルの数は、多くの操作のパフォーマンス * に影響します。

• git status が遅くなることがある (すべてのファイルに対して統計が実行され、インデックス ファイルが肥大化する)
• git commit も遅くなる可能性がある (やはり、すべてのファイルに対して統計が実行される)

* これは、ページ キャッシュと基盤となるストレージ レイヤーによって異なり、数万または数十万にのぼる大量のファイルがある場合にのみ注目に値します。

単一のサブツリー/プロジェクト内に大きなファイルがあると、リポジトリ全体のパフォーマンスに影響します。たとえば、単一リポジトリ内の iOS クライアント プロジェクトに大きなメディア アセットが追加されると、まったく無関係なプロジェクトに取り組んでいる開発者 (またはビルド エージェント) にもそのアセットがクローンされます。

ファイルの数、変更頻度、サイズなどの問題が組み合わさると、パフォーマンスに与える影響が大きくなります。

• サブツリーのコンテキスト (作業中のサブツリーなど) で便利なブランチ/タグの切り替えを行っても、ツリー全体が更新されます。このプロセスは、影響を受けるファイルの数が多いために時間がかかる場合があり、回避策が必要です。たとえば、git checkout ref-28642-31335 -- templates を使って ./templates ディレクトリを指定されたブランチに一致させると、たとえ HEAD を更新していなくても、更新されたファイルが変更済みとしてインデックスでマークされるという副作用があります。
• すべての情報が転送前にパックファイルに圧縮されるため、クローン作成とフェッチは遅くなり、サーバーのリソースを大量に消費します。
• ガベージ コレクションは低速で、既定ではプッシュ時にトリガーされます (ガベージ コレクションが必要な場合)。
• リソース使用率は、git upload-pack, git gc など、パックファイルの (再) 作成を伴うすべての操作で高くなります。

モノリシック リポジトリでありがちな特殊な使用例を Git がサポートできればすばらしいことですが、Git が大成功し、人気を博した原動力であった Git の設計目標は、その目標とは異なる方法で使用したいという欲求と両立しないことがあります。大半のチームにとっての朗報は、実際に本当に大規模なモノリシック リポジトリは例外的であるため、この記事と同様に興味深いことに (そう願います)、モノリシック リポジトリはみなさんが直面している状況には当てはまらない可能性が高いでしょう。

とはいえ、大規模なリポジトリで作業するときに役立つさまざまな緩和戦略があります。長い履歴や大きなバイナリ アセットを持つリポジトリについて、同僚の Nicola Paolucci がいくつかの回避策を述べています。

リポジトリに数万個の ref がある場合、不要になった ref を削除することを検討する必要があります。DAG では、変更がどのように進化したかを示す履歴が保持されますが、マージ コミットではその親が指し示されるので、ブランチが存在しなくなっても、ブランチで行われた作業を追跡できます。

ブランチ ベースのワークフローでは、保持したい長期間存続するブランチの数を少なくする必要があります。マージ後に、存続期間の短いフィーチャー ブランチを思い切って削除してください。

master や production などの main ブランチにマージされたすべてのブランチを削除することを検討してください。main ブランチからコミットに到達可能で、ブランチをマージ コミットでマージしている限り、変更がどのように進化したかを示す履歴を追跡することは引き続き可能です。既定のマージ コミット メッセージにはブランチ名が含まれていることが多く、必要に応じてこの情報を保持できます。

リポジトリに大量のファイル (数万から数十万) がある場合、バッファ キャッシュとして使用できる十分なメモリを備えた高速ローカル ストレージを使用すると役に立ちます。これは、たとえば、Facebook が Mercurial 用に実装した変更と同様の、大きな変更がクライアントにとって必要になる領域です。

同社のアプローチでは、すべてのファイルを反復処理して変更があったかどうかを確認する代わりに、ファイル システム通知を使用してファイルの変更を記録しました。同様のアプローチ (やはり watchman を使用) が git でも議論されていますが、まだ実現されていません。

このセクションは 2016 年 1 月 20 日に更新されました

動画やグラフィックなどの大容量ファイルを含むプロジェクトの場合、Git LFS は、リポジトリのサイズと全体的なパフォーマンスへの影響を制限するための 1 つの選択肢です。Git LFS は、大容量オブジェクトをリポジトリに直接格納する代わりに、このオブジェクトへの参照を含む同じ名前の小さなプレースホルダー ファイルを保存します。このオブジェクト本体は、専用の大容量オブジェクト ストアに格納されます。Git LFS は Git のネイティブ プッシュ、プル、チェックアウト、フェッチ操作にフックして、ワークツリー内のこれらのオブジェクトの転送と置換を透過的に処理します。つまり、リポジトリのサイズが肥大化するというペナルティなしに、通常どおりリポジトリ内の大容量ファイルを操作できます。

Bitbucket Server 4.3 (以降) には、完全に準拠した Git LFS v1.0 以降の実装が組み込まれており、LFS によって追跡される大容量画像アセットのプレビューと差分を Bitbucket UI 内で直接行うことができます。

私の同僚であるアトラシアンの Steve Streeting は、LFS プロジェクトに積極的に貢献しており、最近このプロジェクトについて記事を書きました。

最も根本的な回避策は、単一リポジトリをより小さく、より集中した git リポジトリに分割することです。1 つのリポジトリですべての変更を追跡するのではなく、場合によってはリリース サイクルが似ているモジュールやコンポーネントを特定してコンポーネントの境界を特定することを試みてください。明確なサブコンポーネントの試金石は、リポジトリ内でタグを使用してみて、ソース ツリーの他の部分でタグが意味をなすかどうかを調べる方法です。

Git が単一リポジトリをエレガントにサポートできればすばらしいことですが、単一リポジトリの概念は、そもそも Git が大成功を収め、人気を博している理由と少し矛盾しています。しかし、このことは、単一リポジトリを使用しているからといって、Git の機能をあきらめるべきだという意味ではありません。ほとんどの場合、どのような問題が発生しようとも、実行可能な解決策があります。