另一种方式来做一个大型回购的初步推动 [英] Alternative way to do an initial push of a large repo

问题描述

我在开发和生产中有一个大型的Rails 3.1应用程序，我只在Heroku上设置了一个登台环境。因为我的git repo非常大，每次尝试推送时，我都会收到33％的超时错误。

对于这个初始的巨大推动，有没有替代做 git push staging master ？

错误消息是：

  EmBP-2：Appname Emma $ git push staging master 
计数对象：17421，完成。 
使用多达4个线程的增量压缩。 
压缩对象：100％（6363/6363），完成。 
连接到10.10.18.33被远程主机关闭.46 KiB / s 
错误：pack-objects死于信号13 
错误：未能将一些文件推送到'[e-mail]： appname-staging.git'
  

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

现在有一种巧妙解决方法，使用Heroku的（实验性）管道功能，如果你已经有一个你已经推送了代码的环境。从Heroku 文档：

例如，您可以将代码推送到分段，将其内置到一个slu and中，然后将分段段落推到生产中。

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

解决方案

另一种方法是将您的巨型承诺分解为许多小型承诺。在做这个之前，标记或分支。每个文件都有一些合理的文件。让一个临时分支指向提示。现在将master重置为第一个较小的提交。推。将主设置为下一个提交。推。重复此操作直到完成。

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

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.

Is there an alternative to doing git push staging master for this initial giant push?

The error message is

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 '[e-mail]:appname-staging.git'

/////////////////// SOLUTION / EDIT, many months later...

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:

"For example, you can push code to staging, have it built into a slug and later promote the staging slug to production."

Takes about 5 seconds for Heroku to push the existing slug from one app to another!

解决方案

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.

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屋！