初始推送大型回购的替代方法

Question

我有一个大型 Rails 3.1 应用程序正在开发和生产中，我刚刚在 Heroku 上设置了一个暂存环境。因为我的 git repo 非常大，所以每次尝试推送时都会出现大约 33% 的超时错误。

对于这个最初的巨大推动，除了git push staging master，还有其他选择吗？

错误信息是

EmBP-2:Appname Emma$ git push staging master
Counting objects: 17421, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6363/6363), done.
Connection to 10.10.18.33 closed by remote host.46 KiB/s    
error: pack-objects died of signal 13
error: failed to push some refs to 'git@heroku.com:appname-staging.git'

///////////////// 解决方案/编辑，几个月后......

如果您已经设置了将代码推送到的环境，那么现在有一种偷偷摸摸的方法可以解决这个问题，使用 Heroku 的（实验性）管道功能。来自 Heroku docs:

“例如，您可以将代码推送到 staging，将其内置到 slug 中，然后将 staging slug 提升到生产环境。”

Heroku 将现有 slug 从一个应用程序推送到另一个应用程序大约需要 5 秒！

Answer 1

我试图通过视频推送一些更改并得到：

fatal: The remote end hung up unexpectedly
error: pack-objects died of signal 13
error: failed to push some refs to 'git@github.xxxx/XXX.git'

我的解决方案是：

git repack
git push 

希望这会有所帮助

Answer 2

另一种方法是将您的巨大承诺分解成许多小的承诺。在执行此操作之前标记或分支。每个都会有一些文件构成合理的推送。制作一个临时分支以指向尖端。现在将 master 重置为第一个较小的提交。推。将 master 设置为下一次提交。推。重复此操作直到完成。

现在将 master 恢复到原来的位置。您已经转移了对象。推送这个大提交不应该重新发送远程已经存在的所有对象。

Answer 3

根据 Adam 的回答，您可以将包含许多提交（及其 blob）的大推送分解为多个较小的推送，每个小推送都包含分支历史所需提交的子集。

我之前通过使用临时分支或标签来破坏完整的提交集来完成此操作，但我后来的尝试使用下面的内联脚本。我不必移动 HEAD 或修改索引或工作副本。

您首先需要确定在每次推送的提交数量方面您的积极程度 - 每次推送的提交数量越多可能会稍微快一些，但遇到相同问题的风险更高。此外，由于您的提交将具有不同的大小，因此历史记录中的某些时期可能包含大于平均大小的提交，因此某些块可能会成功，而其他块则需要进一步拆分。您可能还会发现您有一个无法推送的提交，这需要不同的解决方案。

要推送到新的远程分支master，请运行

git log --reverse --oneline | sed -n '0~100p' | awk '{print "git push staging "$1":refs/heads/master"}' | while read i; do eval $i; done

每次推送都会推送接下来的 100 次提交，并且只需要推送在该批提交中找到的新对象（或其增量）。最后，您需要推送当前的HEAD 以推送剩余的提交，并创建最终的远程分支：

git push staging HEAD:master

Answer 4

不，获取内容到 Heroku 的唯一方法是通过 git push。

出于好奇，您的项目文件夹有多大？