20

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

在没有远程压缩对象的情况下阅读git pull后，我怀​​疑二进制文件的增量压缩也会伤害我们，但我不是 100% 确定如何解决这个问题。

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

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

我在做某事吗？

更新：

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

然后我从我的最新工作副本中克隆了一个裸仓库。在工作站之间克隆那个需要大约 5 分钟。然后我将它作为新的仓库推送到服务器。克隆那个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：

此操作后的一些意外副作用：尝试重新打包 git repo 以提高性能后的问题

4

2 回答 2

6

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

听从群众的建议：

  1. 将您的大型二进制文件移出您的存储库
  2. 将您的开发环境移动到虚拟机映像：https ://www.virtualbox.org/
  3. 使用这个 Python 脚本来清理那些大型二进制 blob 的存储库（我在我的存储库中使用它并且效果很好） https://gist.github.com/1433794
于 2012-09-18T20:36:22.477 回答
0

你应该使用不同的机制来存储大二进制文件，如果它们是从你不能存储它们的东西生成的，只是生成它们的代码，否则我建议将它们全部移动到一个目录并使用 rsync 或 svn 管理它取决于你的需要。

于 2012-09-18T20:26:55.750 回答