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

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 文档:

"例如,您可以将代码推送到暂存,将其内置到一个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恢复到原来的位置.您已经转移了对象.推送此大型提交不应重新发送远程已存在的所有对象.