我处于不幸的情况下，必须在git中存储一些二进制文件，
但是我可以选择数据如何存储在磁盘上 - 在Git中（以我们自己的格式，只有构建系统需要读取）。
我想避免过多地谈论细节，因为我认为它不那么重要 - 但是为了给出一些背景，这些是很多图标文件，但同样的问题也适用于许多小型声音文件或3d模型
将这些文件转换为一个大图像将是一个构建步骤，因此我们可以在git中存储图像。
让我们假设偶尔会对某些文件进行更改 - 因此避免为像素的每次小变化存储新的二进制blob都会很好。
我很想知道：
所有事情都考虑了避免大型git仓库的最佳选择（假设对二进制文件进行了编辑）假设使用二进制文件无法完全避免？
答案 0 :(得分：4)
每次二进制文件更改时，哪些选项都会存储一个全新的二进制blob（甚至几个字节）。
所有这些。所有blob（实际上，repo中的所有对象）只要是“松散的对象”，就会“完整”（或多或少）存储。用它们做的唯一事情是给它们一个标题并用压缩压缩压缩它们。
然而，与此同时，松散的物体最终被组合成“包”。 Git对包中的文件执行增量压缩：请参阅Is the git binary diff algorithm (delta storage) standardized?。基于那里的答案，你最好不要“预压缩”二进制文件，这样包文件增量算法可以找到长串的匹配二进制数据。git是否能比压缩数据更好地解压缩二进制数据（即使对未压缩数据进行少量编辑，也可能会发生很大变化）。
我没有尝试过，但总体意义是答案应该是“是”。
我会假设存储许多小二进制文件的长期开销较少，与一个大型二进制文件相比，假设只有一些文件被定期修改，git可以有效地处理大型二进制文件的小变化吗？
当然，所有完全未更改的文件将立即存储大量“重复数据删除”，因为它们的SHA-1校验和在所有提交中都是相同的，因此每个树都命名存储库中的相同blob。如果foo.icon在数千次提交中相同，那么只存储一个blob（无论foo.icon的SHA-1是什么）。
我建议尝试一下：使用建议的二进制文件创建一些虚拟测试回购，进行建议的更改，并查看在运行git gc之前和之后重新包装松散对象的回购站有多大。请注意，有很多可调节的东西;特别是，您可能希望对window，depth和window-memory设置（可以在命令行或git config条目中设置）进行大惊小怪。