对大型回购进行初始推送的替代方法 [英] Alternative way to do an initial push of a large repo
问题描述
我有一个较大的 Rails 3.1 应用程序正在开发和生产中，我刚刚在 Heroku 上设置了一个临时环境.因为我的 git repo 非常大，所以每次我尝试推送时都会遇到大约 33% 的超时错误.
I've got a largish Rails 3.1 app in development and production which I've only just set up a staging environment for on Heroku. Because my git repo is quite large, I'm getting time-out errors at around 33% every time I try to push.
对于这个最初的巨大推送，是否有替代 git push staging master 的替代方法?
Is there an alternative to doing git push staging master for this initial giant push?
错误信息是
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'
///////////////////解决方案/编辑，几个月后......
/////////////////// SOLUTION / EDIT, many months later...
现在，如果您已经设置了一个已将代码推送到的环境，则可以使用 Heroku 的(实验性)流水线功能来解决这个问题.来自 Heroku 文档:
There's a sneaky way to solve this, nowadays, using Heroku's (experimental) Pipeline feature, if you already have an environment set up to which you've pushed the code. From the Heroku docs:
例如，您可以将代码推送到 staging，将其内置到 slug 中，然后将 staging slug 提升到生产环境."
"For example, you can push code to staging, have it built into a slug and later promote the staging slug to production."
Heroku 将现有 slug 从一个应用程序推送到另一个应用程序大约需要 5 秒钟！
Takes about 5 seconds for Heroku to push the existing slug from one app to another!
推荐答案
另一种方法是将巨大的提交分解为许多小的提交.在执行此操作之前标记或分支.每个将有许多文件构成一个合理的推送.制作一个临时分支以指向尖端.现在将 master 重置为这些较小提交中的第一个.推.将 master 设置为下一次提交.推.重复此操作直到完成.
The alternative is to break apart your giant commit into many small ones. Tag or branch before you do this. Each will have a number of files that constitutes a reasonable push. Make a temp branch to point to the tip. Now reset master to the first of those smaller commits. Push. Set master to the next commit. Push. Repeat this until done.
现在将 master 恢复到原来的位置.您已经传输了对象.推送这个大提交不应该重新发送远程已经存在的所有对象.
Now restore master to where it was originally. You already transferred the objects. Pushing this large commit should not resend all the objects that already exist at the remote.
这篇关于对大型回购进行初始推送的替代方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
