git - 修复由于二进制文件大而变慢的 git repo

Question

我们有一个包含源代码和二进制文件的 git 存储库。裸仓库现在已经达到 ~9GB，克隆它需要很长时间。大部分时间花在“远程:压缩对象”上。在使用较大二进制文件之一的新版本提交后，提取需要很长时间，还需要在服务器上压缩对象。

看完git pull without remotely compressing objects我怀疑二进制文件的增量压缩也会对我们造成伤害，但我不是 100% 确定如何解决这个问题。

在服务器上修复裸仓库的具体步骤是什么？我的猜测:

• 为我想要的所有扩展添加像'*.zip -delta'这样的条目到.git/info/attributes
• 运行“git repack”，但有哪些选项？ -adF 会重新打包所有内容，并给我留下一个没有对指定文件类型进行增量压缩的存储库吗？
• 运行“git prune”。我以为这是自动完成的，但是当我玩这个 repo 的裸克隆时运行它减少了 ~2GB 的大小
• 克隆存储库，添加并提交一个 .gitattributes，其中包含我在裸存储库的 .git/info/attributes 中添加的相同条目

我明白了吗？

更新:

一些有趣的测试结果。今天我开始了有问题的 repo 的裸克隆。我们不那么强大的 4GB 内存服务器内存不足并开始交换。 3 小时后我放弃了...

然后我从我最新的工作副本中克隆了一个裸仓库。在工作站之间克隆那个需要大约 5 分钟。然后我将它作为新的 repo 推送到服务器。克隆那个 repo 只用了 7 分钟。

如果我正确地解释了这一点，即使没有禁用二进制文件的增量压缩，一个更好的打包 repo 也会执行得更好。我想这意味着上面的步骤确实是我短期内想要做的，但另外我需要找出如何限制允许 git 用于服务器上打包/压缩的内存量，这样我就可以避免交换。

以防万一:服务器运行 git 1.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 repack -a -d -F --window-memory 100m --max-pack-size 200m
  git gc

更新 3:

此操作后出现一些意想不到的副作用:Issues after trying to repack a git repo for improved performance

Answer 1

虽然您的问题询问如何使您当前的 repo 更有效率，但我认为这不可行。

听从人群的建议:

1. 将大型二进制文件移出存储库
2. 将您的开发环境移动到虚拟机镜像:https://www.virtualbox.org/
3. 使用此 Python 脚本清理那些大型二进制 blob 的存储库(我在我的存储库中使用它并且效果很好)https://gist.github.com/1433794