Git声称当原点按预期接收时它无法推送答案

【问题标题】：Git claiming it cannot push when the origin recieves it as expectedGit声称当原点按预期接收时它无法推送
【发布时间】：2021-07-20 03:18:48
【问题描述】：

我注意到我的 Github 操作失败了，尽管实际输出很好，所以我检查了日志，发现 git 抛出了这些错误：

+ git push origin master
error: RPC failed; curl 56 OpenSSL SSL_read: Connection timed out, errno 110
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly
Everything up-to-date

问题是，实际推送确实通过了。检查 Github，在日志显示推送失败的那一刻，我看到存储库中出现了成功的输出。为什么 git 声称它无法推送，而我可以在我的存储库中看到输出？由于 git 抛出了这个错误，Github 认为我的操作失败了，所以它通过电子邮件向我发送了邮件并抛出了错误，所以我的监控软件提醒我关键工作流程失败了。可能很重要的事情，我正在使用这个 repo 来托管高达 100MB 的二进制文件，而且我有很多。谁能帮我解决这个问题？

【问题讨论】：

相关：serverfault.com/q/1056419/158506
不幸的是，在谈话中有些地方根本无法判断“不合时宜的电话挂断”是在告别握手期间。发生这种情况时，无法区分“正常结束”和“提前终止”。 Git可以插入它自己的结论，如果 Git 这样做并且在那之后发生挂断（在正常连接挂断期间），而不是 Git 依赖于 " normal hangup" 状态结果，Git 会知道一切正常，但 Git 不知道。
即使 Git 确实这样做了，这也只是移动了故障变得神秘的点。所以你可能仍然有同样的问题。唯一要做的就是追踪网络连接本身为什么会这样做，这不是 Git 的事情，也不是 GitHub 的事情，而是网络的事情。
en.wikipedia.org/wiki/Two_Generals%27_Problem

标签： bash git github continuous-integration

【解决方案1】：

当您通过 HTTPS 推送时，会有一个请求，即您推送的数据，以及一个包含状态代码和正文（对于 Git 请求，其中包含消息）的响应。如果您推送数据并且远程端接受了它，但从未成功发送响应，或者该响应被网络问题或干预系统中断，那么 Git 无法知道您的请求是否成功。

在这种情况下，响应表明消息在读取边带响应的过程中被中断，这意味着假设远程端确实完成了处理它是不安全的。因此，Git 在这里失败是正确的。

请注意，有一些可能的原因。如果您要上传大量压缩不佳的二进制文件，那么 Git 可能会合理地花费大量时间来解压缩这些对象，并且可能无法及时发送边带数据包以保持连接有效。理想情况下，您不会在 Git 存储库中存储许多大型二进制文件，因为这对它们来说不是一个很好的用途，但是您可以尝试使用 SSH，而使用 keepalives 可以让连接存活足够长的时间来完成。不过，您不应该将 Git 用作备份或归档解决方案，或工件存储等。

也有可能您的连接确实存在一些网络问题（包括由代理、非默认防病毒或防火墙或 TLS 中间盒引起的问题），在这种情况下，您需要修复所述问题（或卸载或删除所述软件或设备）。有时连接也会中断。

【讨论】：

啊，谢谢你的回答！由于这是在官方 Github 运行器上，网络问题可能不是原因，所以我想我只需将我的更改分成多个推送来解决这个问题。谢谢你的解释！
Whelp，原来我昨晚找到了一个修复程序并忘记了它。添加 git config --global http.postBuffer 524288000 解决了这个问题。
作为the Git FAQ outlines，这意味着您网络上的某些内容已损坏，所以我的回答是成立的。除非有什么东西破坏了您的 HTTP 请求，否则该选项应该不是必需的并且应该没有效果。