Git リポジトリってバイナリファイルが苦手（ソースコード類に比べれば）という話と、巨大なバイナリファイルがまずいという話が効いたことがあっので確認してみました。
確認した環境は Windows 上の 1.9.5-preview20141217 版の git と tortoiseGit でです。以下の内容は特に git vs tortoiseGit で差が無かったので、本体の問題（仕様）だと思います。
- 600M くらいのバイナリファイルを追加
- 2GB弱のバイナリファイルを追加
- 4GB弱のバイナリファイルを追加
これでどうなるか、見てみました。
- 600MB の場合、問題なくファイル追加＆コミットが可能でした。
- 2GB弱の場合、問題なくファイル追加＆コミットが可能でした。
- 4GB弱の場合、ファイルの追加はできたものの、コミット時に 「fatal: Out of memory? mmap failed: No such file or directory」というエラーが出てしまい正しいコミットが出来ない状況です。何度かやってみたら徐々にコミット出来ているように見えましたが、怪しい挙動です。
Pushできるか
コミットの問題もありますが、 Push を行えるかどうかもポイントです。ローカルネット内に準備した GitBucket, GitLab らに対して Push できるかを見てみました。
- GitLab : 600MB 程度のファイルの場合は問題なく Push 可能。それ以外のケースで失敗。
- GitBucket: 2GB弱のファイルの場合には問題なく Push 可能。4GB弱の場合にはエラーで上げられず
GitLab の場合の事前準備
これらの実験の前に、 GitLab の場合には、 HTTP フロントエンドで nginx が使われていたので、 nginx[‘client_max_body_size’] = ‘0’ としてサイズ制限を無効化しています。また unicorn の作業でタイムアウトしてしまうことがあったので、これもまた適当に時間を伸ばしたり、使用メモリ量を増やして対処しています。これらの対処した結果、 600MB 程度なら Push 出来たという感じです。
まとめ
Git は確かに巨大なバイナリファイルは扱いが苦手そうです。そもそもソースコードのバージョン管理にこれらは不要だという考えもわかります。 ただ Git Large File Storage 拡張も出てきましたし、そのうちなんとかなるようになるのかもしれません。
ソースコードだけでなく大きなバイナリファイルもバージョン管理する必要がある場合には、まだ Subversion のほうが使える感じがしますね。個人的にはソースは git, 依存ライブラリパッケージや psdファイルなど大きなファイルについては Subversion に入れるとして、両者をミックスして便利に使えるようになったらいいなーと思いました。
コメント