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

Azure Repos |Azure DevOps Server 2020 |Azure DevOps Server 2019 |TFS 2018 |TFS 2017 |TFS 2015

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

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

Git にどのような種類のファイルを格納する必要がありますか?

ソース コードではなく依存関係

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

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

出力をコミットしない

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

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

更新頻度が低いバイナリ ソース ファイルは、コミットされるバージョンが比較的少なく、ファイル サイズが小さい場合は、非常に多くの領域を取り込む必要があります。 Web、アイコン、その他の小さなアートアセットの画像は、このカテゴリに分類できます。 チームが一貫性のあるワークフローを使用できるよう、これらのファイルをソースの残りの部分と一緒に Git に格納する方が良いです。

重要

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

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

Git は、1 つのメイン バージョンのファイルを管理し、そのバージョンとの違いのみを、deltification と呼ばれるプロセスに格納します。 Deltification とファイル圧縮を使用すると、Git はコード履歴全体をローカル リポジトリに格納できます。 通常、大規模なバイナリはバージョン間で完全に変更され、多くの場合、既に圧縮されています。このため、これらのファイルはバージョン間の違いが非常に大きくなるので、Git で管理するのが困難になります。 Git では、ファイルの各バージョンの内容全体を格納する必要があります。また、削除と圧縮によって領域を節約するのも困難です。 これらのファイルの完全なバージョンを格納すると、リポジトリのサイズが時間のと一度に増加し、分岐のパフォーマンスが低下し、複製時間が長く、ストレージ要件が拡張されます。

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

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

Git Large File Storage (LFS) を使用する

バージョンと頻繁な更新の間に大きな違いがあるソース ファイルがある場合は 、Git LFS を使用してこれらのファイルの種類を管理できます。 Git LFS は Git の拡張機能であり、リポジトリへのコミットで大きなファイルを記述するデータをコミットし、バイナリ ファイルの内容を個別のリモート ストレージに格納します。 リポジトリ内のブランチを複製して切り替える場合、Git LFS は、そのリモート ストレージから正しいバージョンをダウンロードします。 ローカル開発ツールは、ファイルが自分のレポポに直接コミットされた場合と同じ方法で透過的に動作します。

メリット

Git LFS の利点は、チームが作成するファイルに関係なく、使い慣れたエンド エンド を使用して Git ワークフローを終了できるという利点です。 LFS ファイルは、必要に応じて大きくすることができます。 さらに、バージョン 2.0 の Git LFSでは、ビデオ、サウンド、ゲーム マップなどの大規模で問題の発生しない資産に対する作業を支援するファイル ロックがサポートされています。

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

制限事項

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

  1. チームが使用する Git クライアントごとに、Git LFS クライアントをインストールし、その追跡構成 を理解 する必要があります
  2. Git LFS クライアントがインストールされ、正しく構成されていない場合、リポジトリを複製するときに Git LFS によってコミットされたバイナリ ファイルは表示されません。 Git は、実際のバイナリ ファイル自体ではなく、大きなファイル (Git LFS がリポジトリにコミットするファイル) を記述するデータをダウンロードします。 Git LFS クライアントをインストールせずに大きなバイナリをコミットすると、バイナリがリポジトリにプッシュされます。
  3. 両方のバージョンに共通の親がある場合でも、Git は 2 つの異なるバージョンのバイナリ ファイルからの変更をマージできません。 2 人のユーザーが同じファイルを同時に操作している場合は、互いを組み合わせて変更を調整して、相手の作業が上書きされるのを防ぐ必要があります。 Git LFS では、 ファイルロックが役立 ちます。 ユーザーは、作業を開始する前に、常にバイナリ資産の最新のコピーをプルする必要があります。
  4. Azure Repos、Git LFS で追跡されるファイルでのリポジトリでの SSH の使用はサポートされていません。
  5. ユーザーが Web インターフェイスを介してバイナリ ファイルを Git LFS 用に構成されたリポジトリにドラッグ アンド ドロップした場合、バイナリは Git LFS クライアントを介してコミットされるポインターではなく、リポジトリにコミットされます。
  6. ファイル サイズの制限は 50 GB です。
  7. 1 つのファイルアップロードの制限時間は 1 時間です。

ファイル形式

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

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

注意

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

既知の問題

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