クリエイティブ制作物のバージョン管理：Gitとバイナリ資産の運用で起きる問題
画像や動画などのバイナリ資産をGitでそのまま管理すると、リポジトリが際限なく膨らむ。原因はGitが差分をテキスト前提に設計されている点にあり、対策はLFSの事前導入に尽きる。
制作物のバージョン管理にGitを使うチームは多い。コードには最適だが、画像や動画といったバイナリ資産を同じように扱い始めると、しばしば同じ問題に突き当たる。ここでは特定の事例ではなく、繰り返し観察される典型的な失敗を、経過・根本原因・寄与要因・教訓の順に分解する。
バイナリ資産がGitで膨れ上がる経過
典型的な経過はこうだ。最初は数枚の画像をリポジトリに加える。問題は起きない。制作が進むにつれ資産が増え、更新のたびに新しい版がコミットされる。数か月後、リポジトリのクローンに時間がかかるようになり、容量が実際の作業データの何倍にも膨らんでいることに気づく。ここで初めて、履歴に過去のすべての版が蓄積されていた事実が表面化する。
根本原因：Gitはテキストの差分を前提に設計されている
根本原因は、Gitの設計思想にある。Gitはテキストファイルの差分を効率よく保存するよう作られている。バイナリ資産は差分が取りにくく、更新するたびにファイル全体が新しいオブジェクトとして保存される。つまり、一枚の画像を10回更新すれば、10版分の完全なコピーが履歴に残る。作業ディレクトリには最新版しか見えないため、この蓄積は気づきにくい。
寄与要因：LFSの未導入と履歴の肥大化
根本原因を悪化させる寄与要因が二つある。ひとつは、Git LFS（Large File Storage）を導入しないままバイナリを扱い続けたこと。LFSは大きなファイルを本体の外で管理し、履歴には軽い参照だけを残す。もうひとつは、肥大化に気づいてからの対処が難しいことだ。膨らんだ履歴を掃除するには履歴の書き換えが必要で、これは全員の手元のリポジトリに影響する破壊的な操作になる。一方、コード側の管理手法はクリエイティブコーディング環境の比較で触れたとおり比較的整理されている。
教訓：資産の扱いを最初に決める
ここから引き出せる教訓は明快だ。バイナリ資産の扱いは、最初のコミットの前に決める。LFSは資産が入る前に導入してこそ効果があり、入った後では後始末が重くなる。何をリポジトリに入れ、何を外部で管理するかの線引きを、プロジェクトの初期に定めておく。サブセット化したフォントのような生成物をどう扱うかも、この線引きに含まれる点はWebフォントのサブセット化で触れたとおりだ。
入れる前に決める
Gitとバイナリ資産の問題は、技術的には既知で、対策も確立している。それでも繰り返し起きるのは、対処が必要になる時点では、すでに手遅れに近いからだ。ゆえに要点は、資産が入る前に扱いを決めておくことに尽きる。バージョン管理の設計は、コードだけでなく制作物全体を対象に、最初に考えるべき事柄だ。
