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的（实验性）Pipeline功能有一种偷偷摸摸的解决方法。来自Heroku docs：

“例如，您可以将代码推送到暂存，将其内置到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。

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

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

4 个答案: