【ITニュース解説】DevLog 20250916: [Issue] Binary Design Project Version Control

システムエンジニアを目指す初心者の皆さんにとって、プロジェクト開発における「バージョン管理」という考え方は非常に重要である。これは、私たちが日々の作業で作成するファイルやプログラムの変更履歴を記録し、いつでも過去の状態に戻したり、複数の人が同時に作業を進めたりするための仕組みである。特に、プログラミングコードのような「テキストファイル」だけでなく、画像、動画、3Dモデルといった「バイナリファイル」が大量に含まれるデザインプロジェクトでは、このバージョン管理が大きな課題となることがある。

今回の記事で述べられているのは、まさにその「バイナリデザインプロジェクト」におけるバージョン管理の問題と、その解決策を探る試みである。バージョン管理がないと、まず「過去の特定の時点の状態に完全に戻せる」という安心感がなく、作業の途中で問題が発生した場合に元に戻すのが難しい。また、「いつ、どんな変更があったか」という記録が残らないため、手動で進捗をメモする手間がかかる。さらに、古いバージョンを後で使うかもしれないと考えて、常に新しいファイルを作るたびに古いファイルをコピーして保存するような非効率な方法をとりがちになり、新しいアイデアを試したり、改善を繰り返したりする「イテレーション」（繰り返し作業）の妨げとなる。

現在行われている非効率な方法として、プロジェクト全体を「VHDX」という仮想ハードディスクイメージの形式でまとめて、それをクラウドストレージや外付けハードディスクに「アーカイブ」（保存）するというものがある。これは単なるバックアップに近く、バージョン管理システムとは異なる。デザインプロジェクトのファイルはすぐに巨大化するため、この方法ではアーカイブに時間がかかりすぎ、ディスク容量も大量に消費する。また、どの時点でアーカイブを取るかを慎重に計画する必要があり、非常に手間がかかる。これは、頻繁な変更に対応できる柔軟なバージョン管理とは言えない。

そこで、本格的なバージョン管理システムの導入が検討されている。バージョン管理システムは、大きく分けてテキストファイルの管理を得意とするものと、バイナリファイルの管理にも対応できるものがある。一般的なプログラミングでよく使われる「Git」は、テキストファイルの差分（どこが変更されたか）を効率的に記録し、複数人での共同作業を円滑に進めるのに非常に優れている。しかし、画像や動画のようなバイナリファイルは、少しの変更でもファイル全体が大きく変わるため、Gitのような差分管理の仕組みとは相性が悪い。Gitでバイナリファイルを直接管理しようとすると、リポジトリ（プロジェクトの履歴を格納する場所）がすぐに巨大化し、動作が非常に重くなるという問題がある。

このGitの弱点を補うために登場するのが「Git LFS（Large File Storage）」である。LFSは、大きなバイナリファイルをGitリポジトリの外に保存し、Gitリポジトリ内にはそのバイナリファイルの「ポインタ」（場所を示す情報）だけを置く仕組みである。これにより、Git自体は軽量なテキスト情報だけを扱い、バイナリファイルは別途効率的に管理できるようになる。記事では、Git LFSを慎重に使えば、全くバージョン管理がないよりはずっと良い、という見解が示されている。

別の選択肢として挙げられているのが「Perforce」である。Perforceは、特にゲーム開発や大規模なデザインプロジェクトなど、巨大なバイナリファイルを扱うプロフェッショナルな現場で広く使われているバージョン管理システムである。これは、バイナリファイルの管理に特化しており、パフォーマンスや機能の面で優れているが、一般的に導入や運用にコストがかかる。

そして、もう一つの興味深い選択肢として「Fossil」が紹介されている。Fossilは「単一ユーザー」向けを想定した、シンプルながら強力なバージョン管理システムである。最大の特徴は、プロジェクトのコード、履歴、コメント、タグなど、すべての情報を「SQLite」という軽量なデータベースの「単一ファイル」にまとめて格納する点である。これにより、リポジトリの管理が非常に容易になる。Fossilはバイナリファイルの「差分」や「マージ」（複数の変更を統合する作業）は行わないが、バイナリファイル自体のバージョン管理、履歴の記録、コミットノート（変更内容のメモ）、タグ（特定のバージョンに目印を付ける）の機能は提供する。

しかし、Fossilにもいくつかの制限がある。「SQLite BLOB Size Limit」として挙げられているのは、SQLiteデータベースが個々の「BLOB」（Binary Large Object、バイナリデータを格納する形式）として保存できるサイズに実用上の制限があり、約2GBを超える個別のバイナリファイルは直接格納できないということである。また、非常に多くの巨大なバイナリファイルを扱う場合、単一ファイルのリポジトリ構造が原因で、クローン（リポジトリをコピーする）、同期、コミットといった操作のパフォーマンスに影響が出る可能性がある。

これらの制限を考慮した上で、「妥協戦略」として、大きなバイナリファイルを管理するためのいくつかの方法が提案されている。一つは「Unversioned Files」（バージョン管理しないファイル）である。これは、履歴がそれほど重要でない大きなバイナリファイルは、あえてバージョン管理システムの管理下に置かず、別途管理するという方法である。もう一つは「Repository Segmentation」（リポジトリ分割）である。これは、プロジェクトを複数のリポジトリに分割する方法で、例えばプログラムのソースコードや比較的小さなアセットは一つのリポジトリで管理し、巨大なバイナリファイルは別のリポジトリで管理するというものである。Fossilでは比較的この分割がしやすいとされているが、Gitでもサブモジュールとして扱わずに無視することで同様のことが可能である。

記事の筆者は、多くのゲームプロジェクトで既にGitを使っているが、Git LFSの導入に複雑さを感じているようだ。そのため、今回はFossilを「コード以外のバイナリファイル」のバージョン管理に特化して再試行するという「実験的な提案」をしている。

最終的に採用された「ツールセット」は、複数のシステムを組み合わせたハイブリッドな構成である。 Git: プログラムコードなどの「テキストソース」の管理に利用する。これはGitの得意分野である。 cv: これは「変更履歴を素早く記録する」ためのツールとして言及されているが、一般的なバージョン管理システムとは異なる、よりシンプルなログ記録の用途であると考えられる。 Fossil: 今回の主な課題であった「単一ファイルバイナリ」のバージョン管理に特化して利用する。 Manual whole-disk cloud background: これは最終手段としての「予備計画」であり、ディスク全体をクラウドにバックアップすることで、万が一の事態に備える。

このように、一つの完璧なバージョン管理システムですべてを解決するのではなく、それぞれのツールの強みを活かして組み合わせることで、特定のプロジェクトのニーズに合わせた最適な環境を構築しようとしている。システムエンジニアを目指す上では、このようにプロジェクトの特性やファイルの性質を見極め、適切なツールを選定・組み合わせる能力が求められる。これは、単に技術的な知識だけでなく、課題解決のための思考力も養う上で非常に良い事例となるだろう。