git push对于分支来说非常慢

Question

我们有一个相当大的git仓库(ios app资源).我很欣赏git在使用它时会很慢,但如果我创建一个新分支并编辑几个文件(不是二进制文件)并推送,则需要永远.

感觉整个回购都被推了.我的印象是git只会发送差异,是不是错了？(我知道git存储整个文件的压缩版本,我的意思是我的分支和我从哪里分支的差异).

如果我运行,git diff --stat --cached origin/foo那么我会看到一个简短的文件列表,看起来像我期望的那样,例如34 files changed, 1117 insertions(+), 72 deletions(-).但当我推动它进入Writing objects: 21% (2317/10804)并停止时,好像它正在推动所有2.4GB的二进制数据.

我错过了什么(我用Google搜索了很多)？这是预期的行为吗？我在OS X(Mavericks)和ssh(git@github.com)上使用git 2.2.2.

我在这里发现了一个类似的问题:Git - 推动一个大项目的远程分支是非常缓慢但没有真正的答案.

Answer 1

您正在使用"智能"传输(这是一件好事),因此您可以获得增量,或者更具体地说,"增量压缩".但这并不是说git推动了差异.

push和fetch在这里工作方式相同:在智能传输上,你的git调用遥控器,两端都有一个迷你对话,以确定谁有哪些存储库对象,由SHA-1标识并附加到特定标签(通常是分支)和标签名称,但也允许其他标签).

例如,在这种情况下,你的git打电话给他们并说:"我建议让你把你的分支设置master为SHA-1 1234567....我看到你现在master正好333333...,这是我认为你需要从那里得到的7777777...." 他们应回答"好吧,我需要其中一些,但我已经......".一旦你的git找到了需要发送的内容以及已经存在的内容,你的git就会构建一个包含所有待发送对象的"瘦包" ¹.(这是"使用最多%d个线程进行增量压缩"阶段.)

然后通过智能传输发送最终的薄包; 这是您看到"编写对象"消息的位置.(必须成功发送整个瘦包,之后接收器再次"使用它",git index-pack --fix-thin并将其丢弃到存储库中.)

究竟发送什么数据取决于瘦包中的对象.这应该只是"他们拥有"和"你发送的内容"之间的提交集,以及这些提交所需的任何对象(树和blob),以及您发送的任何带注释的标签以及那些所需的任何对象. ,他们还没有.

您可以通过使用git fetch获取最新信息找到有问题的提交,然后使用git rev-list查看您发送的提交内容.例如,如果你只是要推动事情master:

$ git fetch origin   # assuming the remote name is origin
[wait for it to finish]
$ git rev-list origin/master..master

检查这些提交可能会显示一个非常大的二进制文件,该文件包含在其中一个中间文件中,然后在稍后的提交中再次删除:

$ git log --name-status origin/master..master

如果一个提交有A giantfile.bin,然后一个后续(可能列在git log输出中的第一个)提交D giantfile.bin,你可能会挂起发送blob giantfile.bin.

如果是这种情况,您可以使用git rebase -i消除添加巨型二进制文件的提交,这样git push就不必发送该提交.

(如果您的历史记录是线性的 - 没有合并可以推送 - 那么您也可以或者使用它git format-patch来创建一系列包含补丁的电子邮件.这些适用于通过电子邮件发送给其他网站的某个人 - 而不是有人在github等待接收它们,但您可以轻松检查补丁文件,看看它们中是否有巨大的数据.)

¹该包"很薄",因为它违反了正常的包文件规则,该规则要求任何增量压缩"下游"对象都在包本身中.相反,"下游"对象(实际上必须)可以在接收瘦包的存储库中.