Articles /

Gitラージファイルストレージのしくみ。 Overview of Git Large File Storage

世界中の開発チームは、ソースコードを管理するためにGitを使っています。 そして多くは、大容量ファイルを管理・保存するために Git LFS – Git Large File Storage – を使っています。 ここでは、Git LFS が何をするのか、いつ使うのかを説明します。

Can Git Handle Large Files?

Git はそれ自体で大きなファイルを扱うことはできません。 そのため、多くの Git チームは、Git で大きなファイルを扱うために Git LFS を追加しています。

Git LFS (Git Large File Storage) とは何ですか？

Git LFS は、個別の Git リポジトリで大きなファイルやバイナリ ファイルを管理するために使用する Git 拡張機能です。

今日のほとんどのプロジェクトには、コードとバイナリ資産の両方があります。 そして、Git リポジトリに大きなバイナリ ファイルを格納することは、Git ユーザーにとってボトルネックとなり得ます。

そのため、一部の Git ユーザーは Git Large File Storage (LFS) を追加しています。

How Does Git LFS Work?

Git LFS は実際のファイルまたはバイナリー ラージ オブジェクト (blob) の代わりにポインターを使用します。

つまり、Git リポジトリに大きなファイル/ブロブを書き込む代わりに、ポインター ファイルを書き込むのです。 そして、ファイル/ブロブそのものは、別のサーバーに書き込まれます。 Git LFS では複数のサーバーを使用することもできます。

使い始めはかなり簡単です。 拡張機能をダウンロードし、ファイル タイプを設定します。

Git LFS を使用すると、Git リポジトリのスペースを解放しながら、大きなファイルをバージョン管理（およびブロブ管理）することが可能になります。 そして Git LFS はしばしば、大きなファイルを GitHub にプッシュするための修正となります。

Git Problems Beyond LFS

GitにはGit LFS以外にも問題があります。 そして、セキュリティが大きな問題です。 ネイティブのGitはセキュリティに欠けていますし、Gitを安全にするためのアドオン・オプションもあまり良いものではありません。 Gitのセキュリティについて何をすべきかは、ホワイトペーパー「How to Lock Down Git」でご確認ください。

Lock Down Git

Should I Use Git LFS?

大きなファイルやバイナリファイルを Git リポジトリに格納する場合は、Git LFS を使うべきです。

それは、Git が非中央集権的だからです。 そのため、すべての開発者が自分のコンピューターに完全な変更履歴を持っています。 そして、大きなバイナリ・ファイルの変更は、ファイルが変更される（そしてその変更がコミットされる）たびに、Git リポジトリをそのファイルのサイズ分だけ大きくしてしまいます。 つまり、ファイルを取得するのに何年もかかってしまうのです。 そして、もし入手できたとしても、バイナリのバージョン管理やマージが難しくなります。

つまり、ファイルが大きくなるたびに、Git リポジトリが大きくなってしまうのです。 そして、Gitユーザーがリポジトリを取得したりクローンしたりする必要があるとき、これは問題を引き起こします。

Git LFS は、これらの問題を解決するために作成されました。 しかし、それ自体にも問題があります。

When Git Large File Storage Doesn’t Work

Git LFS は動作します。 しかし、チームからは常に、管理するのが難しいという声が聞かれます。

すべてのサーバーとワークステーション (および/または、リポジトリ) に Git LFS をインストールするのは時間がかかります。 また、管理者にも負担がかかります。 いったんインストールされると、それに対する可視性はなく、コントロールもほとんどできません。 もし開発者の中にGit LFSエクステンションを持っていない人がいたら？ それは破綻しています。

JenkinsのようなビルドランナーでGit Large File Storageを維持するには、余分な手順が必要です。

これらすべてがパフォーマンスの問題につながります。

Git LFS の代替手段

Git LFS は Git で大きなファイルを管理する唯一の方法というわけではありません。 代替手段があります。

これには、次のような他のオープン ソースまたはサード パーティの修正が含まれます。

  • git-annex
  • git-bigfiles
  • git-fat
  • git-media
  • git-bigstore
  • git-sym

しかし Git LFS と同じで、これらの Git 大容量ファイルの保存オプションも問題を引き起こすことがあります。 大容量ファイルやバイナリファイルを管理するためのより良い方法があります。

The Best Version Control for Large Binary Files（大きなバイナリ ファイルに最適なバージョン管理）。 Helix Core

今日のプロジェクトは大規模で、これまで以上に多くのファイルや混合アセットが存在します。 Git と Git LFS だけではそれを管理することはできません。

Perforce のバージョン管理ソフトウェアである Helix Core は、大きなバイナリ ファイルを管理するための最適なオプションです。 なぜなら、大容量ファイルの保存はアドオンではなく、ネイティブの機能だからです。

Helix Core では、ソース コードと一緒にバイナリを保存できます。 実際、バイナリ ファイル、ソース コード、アート ファイル、ビデオ ファイル、イメージ、ライブラリ、およびビルド成果物など、すべての最大ファイルを 1 つのリポジトリに格納できます。

なぜHelix Coreが大規模なバイナリファイルの管理に最適なツールなのか、ご自身でお確かめください。

Helixコアで大規模ファイルを管理

ところで、PerforceにはGitもあります

まだ、Gitで大規模ファイルを管理する必要があるとお考えでしょうか。 Perforce の Git ツールである Helix4Git と Helix TeamHub を使用して、ビルド・パイプラインにそれらを取り入れることができます。

Helix4GitはPerforceサーバーの中にあるGitサーバーです。 Helix TeamHub は、Git コード ホスティング ソリューションです。 これらのツールにより、GitチームはHelix Coreのスピードとパフォーマンスを活用しながら、Gitで作業することができます。

つまり、Helix4Git を Helix Core と一緒に使用して、Git リポジトリをビルド・パイプラインに取り込むことができます。 Helix4Gitを使用すると、開発者はネイティブのGitツールを使用できます。

以下を実現します。

  • より高速な CI/CD ビルド パフォーマンス。
  • 複数リポジトリ プロジェクト、アーティファクト リポジトリ、および Docker コンテナーレジストリもサポート。
  • ノードを徐々に追加可能。
  • コピーではなく、遅延なしで複製と最新コンテンツの保証。

Leave a Reply