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

Question

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

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

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

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

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

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

我有兴趣知道：

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

假设不能完全避免使用二进制文件，所有考虑到避免大型 git 存储库（因为对二进制文件进行编辑）的最佳选择是什么？

Answer 1

每次二进制文件更改（甚至几个字节）时，哪些选项将存储一个全新的二进制 blob。

他们都。每当它们是“松散对象”时，所有 blob（实际上，repo 中的所有对象）都会“完整地”（或多或少）存储。对它们所做的唯一一件事就是给它们一个标头并使用 deflate 压缩来压缩它们。

但与此同时，松散的物体最终会组合成“包”。Git 对包中的文件进行增量压缩：请参阅git 二进制差异算法（增量存储）是否标准化？. 根据那里的答案，您最好不要“预压缩”二进制文件，以便包文件增量算法可以找到匹配二进制数据的长字符串。

git diff 未压缩的二进制数据是否比压缩数据更好（即使对未压缩数据进行轻微编辑，也可能发生很大变化）。

我没有尝试过，但总体而言，这个问题的答案应该是“是”。

我认为与一个大型二进制文件相比，长期存储许多小型二进制文件的开销较小，假设只有一些文件被定期修改，git 可以有效地处理对大型二进制文件的小改动吗？

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

我建议尝试一下：使用建议的二进制文件创建一些虚拟测试存储库，进行建议的更改，并查看在git gc重新打包松散对象之前和之后的存储库有多大。请注意，有很多可调参数；特别是，您可能想要对window,depth和window-memory设置（可以在命令行或 git 配置条目中设置）大惊小怪。