不幸的是，我不得不在git中存储一些二进制文件，
但是，我可以选择将数据存储在磁盘上的方式-以Git（采用我们自己的格式，只有构建系统需要读取）。
我想避免过多地谈论细节，因为我认为它没有那么重要-但在某些情况下，这些图标文件很多，但是同一问题也适用于许多小型声音文件或3d模型。
将这些文件转换为一个大图像将是一个构建步骤，因此可以按照我们喜欢的方式在git中存储图像。
让我们假设某些文件偶尔会发生更改-因此避免为像素的每一次小更改都存储一个新的二进制Blob-会很好。
我有兴趣知道：
假设无法完全避免使用二进制文件，所有考虑过的事情是避免大型git repo（对二进制文件进行编辑）的最佳选择是什么？
每当二进制文件更改（甚至几个字节）时，哪些选项将存储一个全新的二进制blob。
他们都是。只要它们是“松散的对象”，所有的blob（实际上是仓库中的所有对象）都会“完整”（或多或少）存储。对它们进行的唯一操作是为它们提供标头，并使用deflate压缩对其进行压缩。
但是，与此同时，松散的物体最终会组合成“包装”。Git对文件包中的文件进行增量压缩：请参阅git二进制diff算法（增量存储）是否标准化？。根据那里的答案，最好不要对二进制文件进行“预压缩”，以便打包文件增量算法可以找到匹配二进制数据的长字符串。
git diff与未压缩的二进制数据相比，未压缩的数据好吗（即使对未压缩的数据进行较小的编辑，它也会发生很大的变化）。
我没有尝试过，但总体含义是答案应该是“是”。
与一个大型二进制文件相比，假设一个文件定期进行修改，我假设存储许多小型二进制文件的长期开销较小，git可以有效地处理大型二进制文件的较小更改吗？
当然，所有完全不变的文件都将立即带有大量“重复数据删除”存储，因为它们的SHA-1校验和在所有提交中都是相同的，因此每个树在存储库中都命名相同的blob。如果foo.icon在数千次提交中相同，则仅存储一个blob（无论SHA-1是否用于foo.icon存储）。
我建议尝试一下：用建议的二进制文件创建一些虚拟测试存储库，进行建议的更改，并查看运行git gc以重新包装松散对象之前和之后存储库的大小。请注意，有很多可调参数。特别是，您可能想大惊小怪的window，depth和window-memory设置（可以在命令行或git config条目中设置）。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句