【发布时间】：2012-09-18 19:44:24
【问题描述】：
我们有一个包含源代码和二进制文件的 git 存储库。裸仓库现已达到约 9GB，克隆它需要很长时间。大部分时间都花在“远程：压缩对象”上。在使用较大二进制文件的新版本提交后，获取需要很长时间，还需要在服务器上压缩对象。
在阅读git pull without remotely compressing objects 之后，我怀疑二进制文件的增量压缩也会对我们造成伤害，但我不能 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：
此操作后的一些意外副作用：Issues after trying to repack a git repo for improved performance
【问题讨论】：
-
当我们开始使用 git 时，我们添加了 uC 二进制文件、我们的 rootfs 和工具链，以便能够通过检查 git 修订来获得过去的完整快照。我们对 git 的了解还不够，无法预见其迟缓。我计划正确解决这个问题（一直在查看 git-annex，但不知道 git-bigfiles），但作为一个短期解决方案，我想尽我所能提高当前 repo 的性能。
-
我觉得将您的开发环境/工具链存储在虚拟机中是更好的做法（如果您绝对必须存储不同版本的开发环境，只需在您的存储库之外存储一个新的磁盘映像）。
-
git 附件 (git-annex.branchable.com) 是一个可能的解决方案。
-
“
echo '*.tar.gz -delta' >> info/gitattributes”应该是“echo '*.tar.gz -delta' >> info/attributes”
标签： git