Git仮想ファイルシステムの履歴（GVFS、Git仮想ファイルシステム）

こんにちはHabr！ 記事Git Virtual File System Design Historyの翻訳に注目してください。 継続するには...



Git Virtual File System（Git Virtual File System、以下GVFS）は、2つの主な問題を解決するために作成されました。

• ユーザーが必要とするファイルのみをダウンロードする
• ローカルGitコマンドは、作業ディレクトリ全体ではなく、ユーザーが作業しているファイルのみを考慮する必要があります

私たちの場合、GVFSを使用する主なシナリオは、作業ディレクトリに合計300万個のファイルがあり、合計で270 GBのWindowsリポジトリです。 このリポジトリのクローンを作成するには、100 GBのpackfileをダウンロードする必要があります。これには数時間かかります。 それでもクローンを作成できた場合、チェックアウト（3時間）、ステータス（8分）、コミット（30分）などのすべてのローカルgitコマンドは、ファイル数への線形依存のために時間がかかりすぎます。 これらの困難にもかかわらず、すべてのWindowsコードをgitに移行することにしました。 同時に、gitの人気と公開されている情報の量が移行の主な理由の一部であったため、gitをほとんど手付かずにしようとしました。



GVFSの作成を決定する前に、膨大な数の代替ソリューションを検討したことに注意してください。 以下の記事でGVFSの仕組みについて詳しく説明しますが、ここでは、検討したオプションと仮想ファイルシステムが作成された理由に集中します。

背景

一体型リポジトリなのはなぜですか？

私たちはすぐに最も単純な質問に対処します：なぜ誰もがそのようなサイズのリポジトリを必要とするのでしょうか？ リポジトリのサイズを制限するだけで、すべて問題ありません！ そうだね

それほど単純ではありません。 モノリシックリポジトリの利点については、すでに多くの記事が執筆されています。 Microsoftのいくつかの大規模なチームは、すでにコードを多くの小さなリポジトリに分割しようとしており、その結果、モノリシックリポジトリの方が優れていると考えています。



大量のコードを壊すことは簡単ではなく、すべての問題の解決策ではありません。 これにより、個々のリポジトリのスケーリングの問題は解決しますが、同時に複数のリポジトリへの変更の導入が複雑になり、結果として最終製品のリリースに時間がかかります。 スケーリングの問題を除いて、モノリシックリポジトリの開発プロセスははるかに単純に見えることがわかりました。

VSTS（Visual Studio Team System）

VSTSツールキットは、いくつかの関連サービスで構成されています。 したがって、それぞれを別々のgitリポジトリに配置することで、スケーリングの問題をすぐに取り除き、同時にコードの異なる部分の間に物理的な境界を作成することにしました。 実際には、これらの国境は良いものには至っていません。



まず、いくつかのリポジトリのコードを同時に変更する必要がありました。 そのとき、依存関係の管理とコミットおよびプルリクエストの正しいシーケンスの実行に多くの時間が費やされ、その結果、膨大な数の複雑で不安定なユーティリティが作成されました。



第二に、リリースプロセスがはるかに複雑になりました。 VSTSの新しいバージョンの3週間ごとのリリースと並行して、TeamFoundation Serverのボックスバージョンを3か月ごとにリリースします。 TFSが正しく機能するには、すべてのVSTSサービスを1台のコンピューターにインストールする必要があります。つまり、すべてのサービスは、依存する他のサービスのバージョンを理解する必要があります。 過去3か月間に独立して開発されたサービスをまとめることは、困難な作業であることが証明されています。



最終的に、モノリシックリポジトリで作業する方がはるかに簡単になることに気付きました。 その結果、すべてのサービスは他のサービスの同じバージョンに依存していました。 いずれかのサービスを変更するには、それに依存するすべてのサービスを更新する必要がありました。 したがって、最初にもう少し作業をすることで、リリースにかかる時間を大幅に節約できました。 もちろん、これは、これからは、新しい依存関係の作成と既存の依存関係の管理についてより注意する必要があることを意味しました。

窓

ほぼ同じ理由で、WindowsチームはGitに切り替えることを決定しました。 Windowsコードは、理論的には複数のリポジトリに分割できる複数のコンポーネントで構成されています。 ただし、このアプローチには2つの問題がありました。 まず、リポジトリの大部分が小さいにもかかわらず、約100 GBを占めるリポジトリの1つ（OneCore）については、スケーラビリティの問題を解決する必要があります。 第二に、このようなアプローチは、同時に複数のリポジトリへの変更の導入を容易にするものではありません。

デザイン哲学

開発ツールを選択するという私たちの哲学は、これらのツールがコードの適切な構成に貢献することです。 チームがいくつかの小さなリポジトリでより効果的に作業できると思われる場合は、開発ツールがこれに役立つはずです。 モノリシックリポジトリを使用する場合、チームがより効果的であると思われる場合は、ツールがこれを妨げることはありません。

検討される代替案

そのため、過去数年にわたり、Gitを大規模なリポジトリで動作させるために多くの時間を費やしました。 この問題を解決するために検討したいくつかのオプションをリストします。

Gitサブモジュール

まず、サブモジュールを使用してみました。 Gitを使用すると、リポジトリを別のリポジトリの一部として指定（ 参照 ）できます。これにより、親リポジトリの各コミットで、この親コミットが依存するサブリポジトリのコミットと、親の作業ディレクトリの正確な場所を指定できます。 大きなリポジトリをいくつかの小さなリポジトリに分割するための完璧なソリューションのようです。 そして、サブモジュールを操作するためのコマンドラインユーティリティの開発に数か月を費やしました。



サブモジュールを使用する主なシナリオは、あるリポジトリのコードを別のリポジトリで使用することです。 ある意味では、サブモジュールは同じnpmパッケージとNuGetパッケージ、つまり 親から独立したライブラリまたはコンポーネント。 変更は主にサブモジュールレベルで行われ（最終的には独立した開発、テスト、およびリリースプロセスを持つ独立したライブラリです）、親リポジトリはこの新しいバージョンの使用に切り替わります。



大きなリポジトリをいくつかの小さなリポジトリに分割し、それらを1つのスーパーリポジトリに接着することで、このアイデアを活用できると判断しました。 「git status」を実行し、すべてのリポジトリのコードを同時にコミットできるユーティリティも作成しました。



最後に、このアイデアを放棄しました。 まず、この方法では開発者の生活を複雑にするだけであることが明らかになりました。親と影響を受ける各サブモジュールリポジトリの両方を更新する必要があるため、各コミットは同時に2つ以上のコミットになります。 第二に、Gitには、複数のリポジトリで同時にコミットを実行するアトミックなメカニズムがありません。 もちろん、コミットのトランザクションの性質を担当するサーバーの1つを割り当てることもできますが、結局、すべてが再びスケーラビリティの問題にかかっています。 そして第三に、ほとんどの開発者はバージョン管理システムの専門家になりたくありません;彼らは彼らのためにこれを行う手頃な価格のツールを好むでしょう。 gitを使用するには、開発者は有向非巡回グラフ（DAG、有向非巡回グラフ）の操作方法を学ぶ必要がありますが、簡単ではありませんが、ここではいくつかの疎結合有向非巡回グラフを同時に操作し、チェックアウト/コミット/プッシュの実行順序に従うように依頼しますそれらに。 これはすでに多すぎます。

複数のリポジトリをまとめる

サブモジュールで機能しなかった場合、複数のリポジトリを接着して機能しますか？ 同様のアプローチがrepo.pyでandroidによって行われ、私たちも試してみることにしました。 しかし、良いことは何もありません。 単一のリポジトリ内での作業が簡単になりましたが、同時に複数のリポジトリを変更するプロセスははるかに複雑になりました。 また、異なるリポジトリのコミットは互いに完全に無関係であるため、製品の特定のバージョンに対して異なるリポジトリのどのコミットを選択する必要があるかは明確ではありません。 これを行うには、Gitの上に別のバージョン管理システムが必要になります。

代替Gitストレージ

Gitには、 代替オブジェクトストアの概念があります 。 gitがコミット、ツリー、またはblobを検索するたびに、.git \ objectsフォルダーから検索を開始し、.git \ objects \ packフォルダー内のパックファイルをチェックし、最後に、git設定で指定されている場合、バックアップストレージ機能を検索します。



クローンとフェッチのたびにサーバーから膨大な数のblobをコピーすることを避けるため、ネットワークフォルダーをバックアップストレージとして使用することにしました。 このアプローチにより、リポジトリからコピーされるファイルの数の問題は多少なりとも解決されましたが、作業ディレクトリとインデックスのサイズの問題は解決されませんでした。



Git機能を他の目的に使用する別の失敗した試み。 オブジェクトの再複製を避けるために、Gitでスペアストアが作成されました。 同じリポジトリをセカンダリクローンする場合、最初のクローンのオブジェクトのリポジトリを使用できます。 すべてのオブジェクトとパックファイルはローカルに配置され、それらへのアクセスは即座に行われ、追加のキャッシュは必要ないと想定されています。 残念ながら、バックアップストレージがネットワーク上の別のマシンにある場合、これは機能しません。

浅いクローン

Gitには、クローンコミットの数を制限する機能があります。 残念ながら、この制限はWindowsのような巨大なリポジトリで動作するのに十分ではありません。なぜなら、各コミットはそのツリーとBLOBと共に最大80 GBを消費するからです。 さらに、通常の操作ではほとんどの場合、コミットの内容全体は必要ありません。

さらに、サーフェスクローンでは、作業ディレクトリ内の多数のファイルの問題は解決されません。

部分（ スパース ）チェックアウト

チェックアウトするとき、Gitはデフォルトでこのコミットのすべてのファイルを作業ディレクトリに配置します。 ただし、.git \ info \ sparse-checkoutファイルでは、作業ディレクトリに配置できるファイルとフォルダーのリストを制限できます。 ほとんどの開発者はファイルの小さなサブセットのみで作業するため、このアプローチには大きな期待がありました。 結局のところ、部分的なものには欠点があります：

• 部分的なチェックアウトはインデックスには適用されず、作業ディレクトリにのみ適用されます。 作業ディレクトリのサイズを5万ファイルに制限しても、インデックスには300万ファイルすべてが含まれます。
  
  
  
  
• 部分的なチェックアウトは静的です。 ディレクトリAを含め、誰かが後でディレクトリBに依存関係を追加した場合、部分チェックアウト用のディレクトリのリストにBを含めるまでビルドは中断されます。
  
  
  
  
• 部分的なチェックアウトは、クローンおよびフェッチ操作中にダウンロードされたファイルには適用されないため、チェックアウトが95％のファイルとは無関係でも、ダウンロードする必要があります。
  
  
  
  
• 頻繁なチェックアウトのUX（ ユーザーエクスペリエンス ）は使用するには不便です

上記のすべてにもかかわらず、部分的なチェックアウトは私たちのアプローチの基本的な部分の1つであることが判明しました。

大容量ファイル用のストレージ（ LFS、大容量ファイルストレージ ）

大きなファイルを変更するたびに、Gitの変更履歴にコピーが作成されます。 スペースを節約するために、Git-LFSはこれらの大きなblobファイルをポインターに置き換えます。ファイル自体は別のストレージに配置されます。 したがって、クローンを作成するときは、ファイルへのポインターのみをダウンロードし、チェックアウトしたファイルのみをLFSがダウンロードします。



LFSをWindowsリポジトリで動作させるのは簡単ではありませんでした。 その結果、成功し、リポジトリの合計サイズを大幅に削減することができました。 ただし、多数のファイルとインデックスのサイズの問題はまだ解決していません。 私はこのアプローチを放棄しなければなりませんでした。

仮想ファイルシステム

上記のすべての実験の結果、次の結論に達しました。

• モノリシックリポジトリが唯一の方法
• ほとんどの開発者は、リポジトリ内のファイルの小さなサブセットのみが機能する必要があります。 しかし、彼らがこのリポジトリの任意の部分を変更できることが重要です。
• 大量の変更を加えずに既存のgitクライアントを使用したい

最終的に、仮想ファイルシステムの概念に焦点を合わせることにしました。その主な利点は次のとおりです。

• 必要な最小限のBLOBファイルのみをダウンロードします。 ほとんどの開発者にとって、これは約50〜10万のファイルとその変更履歴を意味します。 リポジトリのほとんどは決してコピーされません。
• ちょっとしたトリックを使えば、開発者が作業するファイルのみをgitに考慮させることができます。 したがって、git statusやgitcheckoutなどの操作は、300万個すべてのファイルで実行された場合よりもはるかに高速になります
• 部分チェックの助けを借りて、使用したファイルのみを作業ディレクトリに配置できます。 さらに重要なことは、各チェックアウトは開発者が必要とするファイルのみに制限されることです。
• 私たちが使用するすべての開発ツールは、変更なしで機能し続けます。ファイルシステムは、要求されたファイルが常に利用可能であることを確認します

ただし、もちろん困難はありません：

• ファイルシステムの開発は簡単ではありません
• パフォーマンスが一番上になければなりません。 ファイルへの最初のアクセスのわずかな遅延は許されるかもしれませんが、同じファイルへの繰り返しアクセスはほとんど瞬時に行われるはずです。
• ファイルへのアクセスの遅延は、プリロードによって削減できます。 原則として、多数の小さなオブジェクトは最大の遅延をもたらします。 例は、非常に小さなgitツリーオブジェクトの膨大な数です
• gitを仮想ファイルシステムで動作させる方法をまだ理解していません。 gitでこれらすべてのファイルが実際にディスク上にあるように見える場合、350万個のファイルをすべてバイパスすることを避けるにはどうすればよいですか？ gitコマンドは部分的なチェックアウト設定に基づいてうまく機能しますか？ gitがあまりにも多くのblobファイルをバイパスする可能性はありますか？

次の記事では、これらの問題がGVFSでどのように解決されたかについて説明します。