Git LFS で大きいサイズのバイナリファイルも Git で管理する

Git LFS（Git Large File Storage）とは、Git で大きいサイズのバイナリファイル（本稿では、ラージファイルと省略して呼びます）をバージョン管理するための仕組みです。Git はその性質から、ラージファイルを扱うにはいくつかの問題をはらんでいて、Git LFS はその問題を解決するための機能を Git の拡張として提供するものです。本稿では Git LFS の概要紹介として、どういった問題が存在していて、どのように解決されるか、さらにどういった問題が解決されないかまでを含め、一気にまとめて紹介したいと思います。

※ 本稿は、別の SNS 上に掲載していた内容に修正・加筆を加え、有料記事として再公開したものになります。

1. Git のラージファイル管理における問題点

まず Git LFS の背景として、ラージファイル管理における問題点を、Git の特徴を抑えつつ紹介します。

1.1 バイナリファイルの管理に不向き

Git はソースコード（テキストファイル）のバージョン管理に特化したツールです。同種のバージョン管理ツールと同様に、バージョン間の差分算出を前提として多くの機能が提供されています。例えば、二つのコミット同士の変更をマージする際には各ファイル間の差分を元に three-way-merging を行いますし、差分圧縮と呼ばれる技術を用いることでリポジトリの最適化が行われます。

一方、バイナリファイルはフォーマットに乏しい点で差分算出が難しく、変更のマージやリポジトリの最適化が機能しません。よって、何も考えずにバイナリファイルを Git でバージョン管理すると、開発メンバー間での変更が衝突してマージ作業に手間取ったり、差分圧縮による最適化が効かないことでリポジトリの肥大化といった問題が発生します。

1.2 各ローカルマシン上でリポジトリを管理する

バージョン管理システムは、リポジトリの扱いから集中管理と分散管理の二つに分類されます。Git は分散管理に分類されるプロダクトで、リポジトリのコピーを各ローカルマシン上で持つことになります。これによってローカルマシン上でのコミットが可能になるなど、集中管理システムと比べて、開発効率の向上がもたらされるものとされています。

一方で、分散管理システムにはデメリットもあります。
・リポジトリ管理が複雑
・ローカルマシンのストレージ負担

１つ目のデメリットは、Git がとっつきにくいものと捉えられる原因として広く知られているものだと思いますし、本稿の内容とは直接関係のないものなので説明は省略します。２つ目のデメリットですが、これは多くのプロジェクトでリポジトリサイズというのは無視できる程度になっているはずで、あまり意識されていないことだと思います。ですが、前述のようにラージファイルを管理対象とする場合にはリポジトリの肥大化が懸念されますので、通常無視できる問題であるリポジトリサイズが無視できない問題となります。

ちなみに、リポジトリのコピーというのは、単に最新バージョンの全てのファイルのコピーを持つだけでなく、過去の全てのバージョンのコピーを持つということを意味していて、ラージファイルの変更が繰り返された場合には、単純計算で変更回数の系数倍サイズのデータを各ローカルマシンが抱えることになります。