次の方法で共有

Git で大きなファイルを管理および格納する

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020

Git は、バージョン間の違いが簡単に選択され、コードが簡単に圧縮されるため、ソース コードのフットプリントを小さく保つのに役立ちます。 圧縮がうまく行われず、バージョン (バイナリなど) 間で完全に変化する大きなファイルは、Git リポジトリに格納されるときに問題が発生します。 Git の高速パフォーマンスは、ローカル ストレージからファイルのすべてのバージョンに対処して切り替える機能から生まれます。

リポジトリ内に大きな不一致のファイル (バイナリなど) がある場合は、変更をコミットするたびに、それらのファイルの完全なコピーをリポジトリに保持します。 これらのファイルの多くのバージョンがリポジトリに存在する場合、コードのチェックアウト、分岐、フェッチ、複製の時間が大幅に増加します。

Git に格納する必要があるファイルの種類は何ですか?

依存関係ではなく、ソース コードをコミットする

チームがエディターやツールを使用してファイルを作成および更新する場合は、チームが Git のワークフローの利点を享受できるように、これらのファイルを Git に配置する必要があります。 他の種類のファイル (DLL、ライブラリ ファイル、チームが作成しないがコードが依存するその他の依存関係など) をリポジトリにコミットしないでください。 パッケージ管理を通じてこれらのファイルをシステムに配信します。

パッケージ管理は、パッケージを展開するときに依存関係をバンドルし、システムにファイルをインストールします。 パッケージは、環境に同じパッケージがインストールされている限り、ある環境でテストされたコードが別の環境で同じように実行されるようにバージョン管理されます。

出力をコミットしない

ビルドとテストからバイナリ、ログ、トレース出力、または診断データをコミットしないでください。 これらは、ソース コード自体ではなく、コードからの出力です。 作業項目追跡ツールまたはチーム ファイル共有を使用して、ログとトレース情報をチームと共有します。

更新頻度の低い小規模なバイナリ ソースを Git に格納する

更新頻度の低いバイナリ ソース ファイルでは、コミットされたバージョンが比較的少なくなります。 ファイル サイズが小さい場合は、領域があまり占有されません。 Web、アイコン、その他の小さいアート アセットの画像は、このカテゴリに分類できます。 チームが一貫したワークフローを使用できるように、これらのファイルを残りのソースと共に Git に格納することをお勧めします。

Important

小さいバイナリでも、頻繁に更新されると問題が発生する可能性があります。 たとえば、100 KB のバイナリ ファイルに対して 100 個の変更では、1 MB のバイナリに対して 10 個の変更と同じ量のストレージが使用されます。 更新の頻度が高いため、バイナリが小さいほど、大きなバイナリよりも分岐のパフォーマンスが低下します。

頻繁に更新される大きなバイナリ資産をコミットしない

Git は、ファイルの 1 つのメイン バージョンを管理し、そのバージョンとの違いのみを 、deltification と呼ばれるプロセスに格納します。 Deltification とファイル圧縮を使用すると、Git でコード履歴全体をローカル リポジトリに格納できます。 通常、大きなバイナリはバージョン間で完全に変更され、多くの場合、既に圧縮されています。 これらのファイルは、バージョン間の違いが大きいため、Git で管理するのが困難です。

Git では、各バージョンのファイルの内容全体を格納する必要があり、deltification と圧縮によって領域を節約するのが困難です。 これらのファイルの完全なバージョンを格納すると、リポジトリのサイズが時間の経過と同時に増加します。 リポジトリ サイズが大きくなると、分岐のパフォーマンスが低下し、複製時間が長くなり、ストレージ要件が拡張されます。

大きなバイナリ ソース ファイルを操作するための戦略

  • データの圧縮アーカイブをコミットしないでください。 ファイルを圧縮解除し、差分ソースをコミットすることをお勧めします。 Git がリポジトリ内のデータの圧縮を処理できるようにします。
  • コンパイル済みコードやその他のバイナリ依存関係のコミットは避けてください。 ソースをコミットして依存関係をビルドするか、パッケージ管理ソリューションを使用してバージョンを設定し、これらのファイルをシステムに提供します。
  • 構成とその他の構造化データを、JSON などの差分プレーンテキスト形式で格納します。

Git LFS とは

バージョンと頻繁な更新プログラムの間に大きな違いがあるソース ファイルがある場合は、 Git Large File Storage (LFS) を使用してこれらのファイルの種類を管理できます。 Git LFS は Git の拡張機能であり、リポジトリへのコミット内の大きなファイルを記述するデータを提供します。 バイナリ ファイルの内容を別のリモート ストレージに格納します。

リポジトリ内のブランチを複製して切り替えると、Git LFS はそのリモート ストレージから正しいバージョンをダウンロードします。 ローカル開発ツールは、ファイルがリポジトリに直接コミットされたかのように透過的に動作します。

メリット

Git LFS の利点は、チームが作成するファイルに関係なく、使い慣れたエンド ツー エンドの Git ワークフローをチームが使用できることです。 LFS は、大きなファイルを処理して、リポジトリ全体に悪影響を与えないようにします。 さらに、バージョン 2.0 以降では、Git LFS は ファイル ロックを サポートしており、チームがビデオ、サウンド、ゲーム マップなどの大きな不一致のアセットに取り組むのに役立ちます。

Git LFS は、Azure DevOps Services で完全にサポートされ、無料です。 Visual Studio で LFS を使用するには、 Visual Studio 2015 Update 2 以降が必要です。 手順に従ってクライアントをインストールし、ローカル リポジトリにファイルの LFS 追跡を設定してから、変更を Azure Repos にプッシュします。

制限事項

Git LFS には、それを採用する前に考慮する必要があるいくつかの欠点があります。

  • チームが使用するすべての Git クライアントは、Git LFS クライアントをインストールし、その 追跡構成を理解する必要があります。
  • Git LFS クライアントが正しくインストールおよび構成されていない場合、リポジトリを複製するときに Git LFS を通じてコミットされたバイナリ ファイルは表示されません。 Git は、バイナリ ファイルではなく、大きなファイル (Git LFS がリポジトリにコミットするファイル) を記述するデータをダウンロードします。 Git LFS クライアントをインストールせずに大きなバイナリをコミットすると、バイナリがリポジトリにプッシュされます。
  • Git では、両方のバージョンに共通の親がある場合でも、バイナリ ファイルの 2 つの異なるバージョンからの変更をマージすることはできません。 2 人が同じファイルで同時に作業している場合は、他のユーザーの作業を上書きしないように変更を調整するために連携する必要があります。 Git LFS では、役立つ ファイル ロックが 提供されます。 ユーザーは、作業を開始する前に、常にバイナリ資産の最新のコピーをプルするように注意する必要があります。
  • 現在、Azure Repos では、Git LFS 追跡ファイルを含むリポジトリでの Secure Shell (SSH) の使用はサポートされていません。
  • ユーザーが Web インターフェイスを介してバイナリ ファイルを Git LFS 用に構成されたリポジトリにドラッグした場合、バイナリは Git LFS クライアント経由でコミットされるポインターではなく、リポジトリにコミットされます。
  • 厳密なファイル サイズ制限はありませんが、サーバーの使用可能な空き領域と現在のワークロードによって、パフォーマンスと機能が制限される可能性があります。
  • 1 つのファイルアップロードの時間制限は 1 時間です。

ファイル形式

Git LFS 追跡ファイルのリポジトリに書き込まれたファイルには、各行にキーと値のペアを含む数行があります。

version https://git-lfs.github.com/spec/v1
oid a747cfbbef63fc0a3f5ffca332ae486ee7bf77c1d1b9b2de02e261ef97d085fe
size 4923023

注

バージョン値に含まれる GitHub URL では、LFS ポインター ファイルの種類のみが定義されます。 バイナリ ファイルへのリンクではありません。

既知の問題

Azure DevOps Server で 2.4.0 より前のバージョンの LFS を使用する場合は、 Kerberos ではなく NTLM 経由で認証するための追加のセットアップ手順が必要です。 LFS 2.4.0 ではこの手順は不要になり、アップグレードすることを強くお勧めします。