Git与二进制数据，最佳存储方式

Question

不幸的是，我不得不在 git 中存储一些二进制文件，

但是我可以选择数据在磁盘上的存储方式 - 在 Git 中(以我们自己的格式，只有构建系统需要读取)。

我想避免过多地谈论细节，因为我认为它不那么重要 - 但为了提供一些上下文，这些是许多图标文件，但同样的问题也适用于许多小的声音文件或 3d 模型.

将这些文件转换成一个大图像将是一个构建步骤，因此可以在 git 中以我们喜欢的任何方式存储图像。

• 二进制压缩(例如，PNG(图像)、FLAC(声音))
• 未压缩的二进制文件(例如 PPM(图像)、未压缩的 WAV(声音))
• 二进制数据的 ASCII 表示(例如，mime 编码、XPM(图像))

假设某些文件偶尔会发生变化 - 所以避免为像素的每个小变化存储新的二进制 blob - 会很好。

我很想知道:

• 每次二进制文件更改(即使是几个字节)时，哪些选项将存储一个全新的二进制 blob。
• git diff 未压缩的二进制数据是否比压缩数据更好(即使对未压缩的数据进行微小的编辑也可能发生很大变化)。
• 我认为与一个大二进制文件相比，存储许多小二进制文件的长期开销要小，假设只有一些文件被定期修改，git 可以有效地处理对大二进制文件的小改动吗？

如果无法完全避免使用二进制文件，那么考虑到所有事情，避免大型 git 存储库(因为对二进制文件进行了编辑)的最佳选择是什么？

Answer 1

Which options will store a totally new binary blob each time the binary file changes (even a few bytes).

所有这些。所有 blob(实际上，repo 中的所有对象)只要是“松散对象”，就会“完整”(或多或少)存储。对它们所做的唯一一件事就是给它们一个 header 并使用 deflate 压缩对其进行压缩。

与此同时，松散的物体最终会组合成“包”。 Git 对包中的文件进行增量压缩:参见 Is the git binary diff algorithm (delta storage) standardized? .根据那里的答案，最好不要“预压缩”二进制文件，这样包文件增量算法就可以找到匹配二进制数据的长字符串。

Does git diff uncompressed binary data better then compressed data (which may change a lot even with minor edits to the uncompressed data).

我还没有尝试过，但总的来说，答案应该是"is"。

I would assume storing many small binary files is less overhead long term, compared to one large binary file, assuming only some of the files are periodically modified, can git handle small changes to large binary files efficiently?

当然，所有完全未更改的文件都将立即进行大量“去重”存储，因为它们的 SHA-1 校验和在所有提交中都是相同的，因此每棵树在存储库中命名完全相同的 blob。如果 foo.icon 在数千次提交中都是相同的，则只会存储一个 blob(无论 foo.icon 的 SHA-1 结果是什么)。

---

我建议进行一些试验:使用建议的二进制文件创建一些虚拟测试 repo 协议(protocol)，进行建议的更改，并查看在运行 git gc 重新打包松散文件之前和之后 repo 协议(protocol)有多大对象。请注意，有很多可调项；特别是，您可能想要对 window、depth 和 window-memory 设置大惊小怪(可以在命令行或 git config 中设置项)。