修复由于大二进制文件而减慢的git回购

我们有一个包含源代码和二进制文件的git repo。裸回购协议现在已经达到了约9GB，克隆它需要很长时间。大部分时间都花在“远程：压缩对象”上。在使用一个较大二进制文件的新版本进行提交后，获取需要很长时间，而且还需要压缩服务器上的对象

在阅读之后，我怀疑二进制文件的增量压缩也会对我们造成伤害，但我不确定如何解决这个问题

修复服务器上的裸回购的确切步骤是什么？我猜：

• 为我想要添加到.git/info/attributes中的所有扩展添加类似“*.zip-delta”的条目
• 运行“git repack”，但有哪些选项？adF是否会重新打包所有内容，并给我留下一个repo，其中没有对指定的文件类型进行增量压缩
• 运行“gitprune”。我原以为这是自动完成的，但当我在玩上述回购协议的裸体克隆时，运行它会将大小减少约2GB
• 克隆repo，添加并提交一个.gittributes，其条目与我在裸repo上的.git/info/attributes中添加的条目相同

我知道什么了吗

更新：

这方面的一些有趣的测试结果。今天我开始复制有问题的回购协议。我们的4GB内存不是很强大的服务器内存不足，开始交换。三个小时后我放弃了

然后，我从最新的工作副本中克隆了一份裸回购协议。在工作站之间克隆一个需要约5分钟。然后，我将其作为新的repo推送到服务器上。克隆回购协议只花了7分钟

如果我正确地解释了这一点，那么即使不禁用二进制文件的增量压缩，更好的打包repo也会执行得更好。我想这意味着上述步骤确实是我短期内想要做的，但除此之外，我还需要了解如何限制git在服务器上打包/压缩时允许使用的内存量，以便避免交换

如果有问题：服务器运行Git1.7.0.4，工作站运行1.7.9.5

更新2:

我在testrepo上执行了以下步骤，我想我有机会在服务器上执行这些步骤（备份后）

• 打包对象时限制内存使用
  git config pack.windowMemory 100m
  git config pack.packSizeLimit 200m

• 禁用某些扩展的增量压缩
  echo'*.tar.gz-delta'>>信息/属性
  echo'*.tar.bz2-delta'>>信息/属性
  echo'*.bin-delta'>>信息/属性
  echo'*.png-delta'>>信息/属性

• 重新打包存储库并收集垃圾
  git重新打包-a-d-F——窗口内存100米——最大封装尺寸200米
  git gc

更新3:

---

此操作后会产生一些意外的副作用：

您应该使用不同的机制来存储大型二进制文件，如果它们是由某些无法存储的内容生成的，则只能使用生成它们的代码，否则，我建议将它们全部移动到一个目录中，并根据您的需要使用rsync或svn进行管理。

虽然您的问题是如何提高当前回购的效率，但我认为这是不可行的

听从人群的建议：

将大型二进制文件移出回购协议

将开发环境移动到虚拟机映像：

使用这个Python脚本清理repo中的那些大二进制blob（我用它来处理我的repo，效果很好）

---

将二进制文件存储到别处是一种选择吗？Git真的很讨厌大的二进制文件，这一点已经得到承认。这就是为什么我们要这么做的原因……当我们开始使用git时，我们添加了uC二进制文件、我们的rootfs和工具链，以便只需查看git版本就可以获得过去的完整快照。我们对git的了解不够，无法预见它的迟钝。我计划正确地解决这个问题（一直在查看git附件，但不知道git bigfiles），但作为一个短期解决方案，我希望尽我所能提高当前repo的性能。我觉得将开发环境/工具链存储在虚拟机中更好（如果您必须存储不同版本的开发环境，只需在repo外部存储一个新的磁盘映像即可）。git附件（）是一个可能的解决方案。“

echo'*.tar.gz-delta'>>info/gittributes

”应该是“

echo'*.tar.gz-delta'>>info/attributes

”合理的建议，但不适用于我们的情况。最大（也是最有问题的）二进制文件是一个tar.bz2'ed rootfs，它需要花费数小时来构建。我想，在这个rootfs上，很少有文件在每次构建时都会得到更改，所以在这种情况下，不压缩它们，而是直接将它们添加到repo中可能更明智（以防不够清楚，将要添加的整个目录添加到tar中，而不是结果tar.bz2文件）这样一来，您的DIFF应该更小，因为Git不能很好地处理差异二进制文件。我完全同意这种策略来实现更持久的修复。而不是使用DEM环境中的VM，我考虑将版本存储在服务器上，而只是将文件中的一个文件放到当前的一个点。但是，您确定当前的回购不可能是MA吗？是否更高效？如果我理解我链接到的帖子，应该可以让它更好一点。如果我能摆脱“远程：压缩对象”只用于将来的抓取（而不是最初的克隆），这本身就会有所帮助。