多くの人がGitをその柔軟性のために選択しました。特に、ブランチアンドマージモデルは、効率的な開発の分散化を可能にします。 ほとんどの場合、この柔軟性はプラスですが、一部のシナリオはそれほどエレガントにサポートされていません。 それらの1つは、大きなモノリシックリポジトリ-モノリポジトリでのGitの使用です。 この記事では、Gitのモノリポジトリーの問題を調査し、それらを軽減する方法を提案します。


モノリスの例としてのオーストラリアのウルルロック -KDPV、これ以上

単一リポジトリとは何ですか？

定義はさまざまですが、以下の条件ではリポジトリがモノリシックであると見なします。

• リポジトリには、複数の論理プロジェクト（たとえば、iOSクライアントとWebアプリケーション）が含まれます
• これらのプロジェクトは、無関係であるか、疎結合であるか、サードパーティの手段によって接続されている場合があります（たとえば、依存関係管理システムを介して）
• リポジトリは多くの点で大きなものです。
  
  • コミット数別
  • ブランチおよび/またはタグの数
  • ファイル数別
  • サイズに合わせる（つまり、 .gitフォルダーサイズ）

モノリポジトリはいつ便利ですか？

私はいくつかの可能なシナリオを見ています：

• リポジトリには、単一の論理アプリケーションを構成する一連のサービス、フレームワーク、およびライブラリが含まれています。 たとえば、 foo.example.comアプリケーションをまとめて提供する多くのマイクロサービスと共有ライブラリ。
• リポジトリーがさまざまな環境（ステージングや実動など）で使用されるため、成果物のセマンティックバージョン管理は不要であるか、あまりメリットがありません。 ユーザーにアーティファクトを送信する必要がない場合、1.10.34などの履歴バージョンが不要になる可能性があります。

このような状況では、大きな変更やリファクタリング（たとえば、すべてのマイクロサービスを特定のバージョンのライブラリに更新する）がはるかに簡単になるため、単一のリポジトリが優先される場合があります。
Facebookには、このような単一リポジトリの例があります 。

1週間に数千のコミットと数十万のファイルがあり、Facebookが巨大な場合のソースのメインリポジトリ-何倍も
2013年時点で、44,000個のファイルに1700万行のコードが含まれていたLinuxカーネルでさえも。

Facebookでパフォーマンステストを実施する際、次のパラメーターを使用してテストリポジトリを使用しました 。

• 400万件のコミット
• リニアストーリー
• 約130万ファイル
• .Gitフォルダーサイズは約15 GB
• 最大191 MBのサイズのインデックスファイル

概念的な問題

関連のないプロジェクトをGitモノリポジトリに保存することには、多くの概念的な問題があります。

最初に、Gitはコミットごとにツリー全体の状態を考慮します。 これは1つ以上の関連プロジェクトでは正常ですが、多くの無関係なプロジェクトがあるリポジトリでは扱いにくいものになります。 簡単に言えば、開発者にとって不可欠なサブツリーは、ツリーの無関係な部分でのコミットの影響を受けます。 この問題は、ツリーの履歴に多数のコミットがあることで明らかに現れます。 ブランチのトップは常に変更されるため、変更を送信するには頻繁にmergeまたはrebase merge必要です。

Git のタグは、特定のコミットへの名前付きポインターであり、順番にツリー全体を参照します。 ただし、モノリポジトリのコンテキストでは、タグの有用性が低下します。 自分自身で判断する：モノリポジトリ（継続的デプロイメント）から常にデプロイされるWebアプリケーションで作業している場合、リリースタグはiOSのバージョン付きクライアントと何の関係がありますか？

パフォーマンスの問題

これらの概念的な問題に加えて、モノリポジトリに影響するパフォーマンスの側面がいくつかあります。

コミット数

関係のないプロジェクトを単一の大きなリポジトリに保持することは、コミットレベルでは面倒です。 時間が経つにつれて、そのような戦略は、多数のコミットと大幅な成長率につながる可能性があります（Facebookの説明- 「1週間に数千のコミット」 ）。 Gitは、プロジェクトの履歴を保存するために有向非周期的グラフ（DAG）を使用するため、特にコストがかかります。 コミットの数が多いと、グラフをバイパスするチームは、履歴が大きくなるにつれて遅くなります。

このようなコマンドの例としては、 git log （リポジトリの履歴の調査）やgit blame （ファイルの変更に注釈を付ける）があります。 最後のGitコマンドを実行する場合、その変更に関する情報を計算するために、調査中のファイルに関連しない一連のコミットをバイパスする必要があります。 さらに、到達可能性の問題を解決することはより困難になります。たとえば、コミットAはコミットBから到達可能ですか？ ここにリポジトリに多くの無関係なモジュールを追加すると、パフォーマンスの問題が悪化します。

ポインターの数（ refs ）

モノリポジトリ内の多数のポインタ（ブランチとタグ）は、いくつかの点でパフォーマンスに影響します。
ポインターアナウンスには、モノリポジトリのすべてのポインターが含まれています。 ポインターのアナウンスはリモートGit操作の最初のフェーズなので、 git clone 、 git fetchまたはgit pushなどのコマンドがヒットします。 多数のポインターを使用すると、パフォーマンスが低下します。 git ls-remoteを使用してポインターのアナウンスを確認し、引数としてリポジトリURLを渡します。 たとえば、このようなコマンドは、Linuxカーネルリポジトリ内のすべてのポインターをリストします。

 git ls-remote git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 

ポインターが圧縮形式で格納されていない場合、ブランチの列挙はゆっくりと動作します。 git gcコマンドが実行されると、ポインターは単一のファイルにパックされ、20,000個のポインターのリストも高速になります（約0.06秒）。

リポジトリのコミット履歴をバイパスし、モノリポジトリの各ポインター（たとえば、 git branch --contains SHA1 ）を考慮する必要がある操作は、動作が遅くなります。 たとえば、21.708のポインターでは、コンピューター上で古いコミット（ほとんどすべてのポインターから到達可能）を含むポインターを検索するのに146.44秒かかりました（この時間は、リポジトリーが格納されているストレージメディアのキャッシュ設定とパラメーターによって異なります）。

カウントされたファイルの数

インデックス（ .git/index ）は、リポジトリ内のすべてのファイルをカウントします。 Gitはインデックスを使用して、ファイルごとにstat(1)を実行し、ファイルの変更情報をインデックスに含まれる情報と比較することにより、ファイルが変更されたかどうかを判断します。

したがって、リポジトリ内のファイルの数は、多くの操作のパフォーマンスに影響します。

• git statusが遅いのは このコマンドはすべてのファイルをチェックし、インデックスファイルは大きくなります
• git commitもすべてのファイルをチェックするため、遅くなる可能性があります

これらの効果は、キャッシュ設定とディスクの特性によって異なり、数万個から数十万個で計算される非常に多数のファイルでのみ顕著になります。

大きなファイル

単一のサブツリー/プロジェクト内の大きなファイルは、リポジトリ全体のパフォーマンスに影響します。 たとえば、単一のリポジトリ内のiOSクライアントプロジェクトに追加された大きなメディアファイルは、まったく異なるプロジェクトで作業している開発者によっても複製されます。

複合効果

ファイルの数とサイズとそれらの変更の頻度の組み合わせにより、パフォーマンスがさらに低下します。

• サブツリー（たとえば、作業中のサブツリー）のコンテキストに関連するブランチまたはタグを切り替えても、ツリー全体が更新されます。 影響を受けるファイルの数が多いため、このプロセスは遅くなる可能性がありますが、 回避策があります。 たとえば、次のコマンドは./templatesフォルダーを更新して、指定されたブランチと一致するようにしますが、副作用を引き起こすHEADは変更しません：更新されたファイルは、インデックスで変更済みとしてマークされます。
  

   `git checkout ref-28642-31335 -- templates` 

• すべての情報が送信前にパックファイルにパックされるため、クローン作成とダウンロード（フェッチ）が遅くなり、サーバーのリソースを大量に消費します。
• ガベージコレクションは長くなり、 git push実行時にデフォルトで呼び出されます（コレクション自体は必要な場合にのみ発生します）。
• パックファイルの作成を含むコマンド（たとえば、 git upload-pack 、 git gc ）には、かなりのリソースが必要です。

Bitbucketはどうですか？

説明した効果の結果として、モノリシックリポジトリはGitリポジトリ管理システムのテストであり、Bitbucketも例外ではありません。 さらに重要なことは、モノリポジトリによって生成される問題には、サーバー側とクライアントの両方で解決策が必要です。

パラメータ	サーバーへの影響	ユーザーへの影響
大きなリポジトリ（多くのファイル、大きなファイル、またはその両方）	メモリ、CPU、IO、 git cloneのネットワークへのロード、 git gc遅く、リソースをgit gc消費します	開発者とCIの両方にとって、クローニングには多くの時間がかかります
多数のコミット	-	git logとgit blameが遅い
多数のポインター	ブランチのリストを表示し、ポインターをアナウンスするには時間がかかります（ git fetch 、 git clone 、 git pushは遅いです）	可用性が低下する
多数のファイル	サーバー側のコミットが長くなる	git statusとgit commitが遅い
大きなファイル	「大規模リポジトリ」を参照してください	大きなファイルのgit add 、 git pushおよびgit gcが遅い

緩和戦略

もちろん、Gitがモノリシックリポジトリでのユースケースを具体的にサポートしてくれたら素晴らしいと思います。 大多数のユーザーにとって朗報は、実際には、ルールではなく実際に大きなモノリシックリポジトリが例外であるため、この記事が興味深いものになったとしても（あなたが望むもの）、そうした状況には当てはまらない可能性があることです。あなたが出くわした。

上記のマイナスの影響を軽減する方法はいくつかあり、大規模リポジトリでの作業に役立ちます。 長い歴史のあるリポジトリや大きなバイナリファイルについては、同僚のNicola Paolucciがいくつかの回避策を説明しました。

ポインターを削除する

リポジトリ内のポインターの数が数万個の場合、不要になったポインターを削除する必要があります。 コミットグラフは変更の進化の履歴を保持します。また、マージコミットにはすべての親へのリンクが含まれるため、ブランチ自体が存在しなくても、ブランチで行われた作業を追跡できます。 さらに、マージコミットには多くの場合、ブランチの名前が含まれており、必要に応じてこの情報が復元されます。

ブランチベースの開発プロセスでは、保持する必要のある長命ブランチの数は少なくする必要があります。 短期的な機能ブランチをメインブランチにマージした後に削除することを恐れないでください。 メインブランチに既にマージされているすべてのブランチを削除することを検討してください（たとえば、 masterまたはproduction ）。

多数のファイルを処理する

リポジトリに多数のファイルがある場合（その数は数十万から数十万に達します）、高速ローカルディスクとキャッシュに使用できる十分なメモリが役立ちます。 この領域には、 FacebookがMercurialに実装したものと同様に、より重要なクライアント側の変更が必要になります。

彼らのアプローチは、ファイルシステムイベントを使用して、それらを検索するすべてのファイルを反復処理するのではなく、変更されたファイルを追跡することです。 Gitについても 、ファイルシステムを監視するデーモンを使用した同様のソリューションが説明されましたが、現時点では結果が得られていません。

Git LFS（大容量ファイルストレージ）を使用する

ビデオやグラフィックスなどの大きなファイルを含むプロジェクトの場合、 Git LFSはリポジトリのサイズと全体的なパフォーマンスへの影響を軽減する1つの方法です。 リポジトリ自体に大きなオブジェクトを保存する代わりに、Git LFSは同じ名前でこのオブジェクトへの小さなポインターファイルを保存します。 オブジェクト自体は、大きなファイルの特別なリポジトリに保存されます。 Git LFSはpush 、 pull 、 checkoutおよびfetch操作と統合しpush 、これらのオブジェクトの作業コピーへの転送と置換を透過的に提供します。 これは、リポジトリを膨張させることなく、通常と同じ方法で大きなファイルを操作できることを意味します。

Bitbucket Server 4.3 はGit LFS v1.0 +を完全にサポートし 、さらに、LFSに保存されている大きなグラフィックファイルを表示および比較できます。



同僚のスティーブストリートは LFSプロジェクトの開発に積極的に関与しており、最近彼に関する記事を執筆しました 。

境界を定義し、リポジトリを分割します

最も根本的な解決策は、モノリポジトリをより小さく、より焦点の合ったリポジトリに分割することです。 単一のリポジトリ内のすべての変更を追跡するのではなく、たとえば、共通のリリースサイクルを持つモジュールまたはコンポーネントを強調表示することにより、コンポーネントの境界を識別するようにしてください。 コンポーネントの良い兆候は、リポジトリでのタグの使用と、ソースコードツリーの他の部分にどの程度意味があるかです。

モノリポジトリの概念は、Gitを非常に成功させ人気のあるものにしたソリューションとは異なりますが、これは、リポジトリがモノリシックであるという理由だけでGitの機能を放棄する必要があることを意味するものではありません：ほとんどの場合、発生する問題に対する実用的なソリューションがあります。

---

Stefan ZaazenはAtlassian Bitbucketのアーキテクトです。 DVCSへの情熱により、彼はConfluenceチームをSubversionからGitに移行し、最終的には現在Bitbucket Serverとして知られているものを開発する道をリードしました。 ステファンはツイッターで@stefansaasenという仮名で見つけることができます。