简单的解决方案是增加HTTP post缓冲区的大小，以允许将更大的块推送到远程存储库。要做到这一点，只需键入：

git config http.postBuffer 52428800

该数字以字节为单位，因此在本例中，我将其设置为50MB。默认值为1MB。

我在VMWare上使用arch发行版时遇到了这个问题。
添加
IPQoS=throughput
到我的ssh配置（~/.ssh/config）为我做了这件事。

因为我还没有看到这个答案：更改您的Wifi网络。我的是阻止我，给了我broken pipe错误。在使用我的iPhone作为热点后，它工作得很完美！

我遇到了同样的问题，这对我很有效：

git gc --aggressive --prune

这花了一段时间，但在完成之后，所有的git操作都开始运行得更快了。
之前失败的推送操作随后成功，可能是因为它变得足够快，以避免一些超时相关的问题。

请注意，当一个push的包文件损坏（即pack-objects失败）时，它仍然可以冻结（即使postBuffer增加）
这将在git 2中修复。9（2016年6月）。更好地使用Git 2。25（2020年第一季度）
参见commit c4b2751，commit df85757，commit 3e8b06d，commit c792d7b，commit 739cf49（2016年4月19日）by Jeff King ( peff )。
（由Junio C Hamano -- gitster --合并到commit d689301，2016年4月29日）
“git push”来自损坏的存储库，该存储库试图推送大量死锁的引用;在接收端的主线程注意到推送失败并决定不读取这些通知并返回失败之后，中继这些REF更新的拒绝通知的线程在将它们写入主线程时被阻止。
Commit 739cf49有所有的细节。

send-pack：在完成异步进程之前关闭解复用管道

这修复了从损坏的repo推送大量引用时客户端的死锁。
在Git 2.25（2020年第一季度）中，“git push”完成发送packdata并等待远程端响应后的错误处理得到了改进。
参见commit ad7a403（2019年11月13日），作者Jeff King ( peff )。
（由Junio C Hamano -- gitster --合并至commit 3ae8def，2019年12月1日）

send-pack：检查pack-objects失败时的远程引用状态

协助人：SZEDER Gábor
签字人：杰夫·金
当我们推送一个包并且本地包对象失败时，我们输入一个错误代码路径，它会做一些事情：
1.将每个引用的状态设置为REF_STATUS_NONE
1.调用receive_unpack_status()以尝试从另一端获取错误报告
1.向调用方返回错误
如果pack-objects因为与服务器的连接断开而失败，那么除了报告挂起之外，我们没有别的办法了。实际上，步骤2将尝试从另一端读取数据包，这将在数据包读取代码中使用“the remote end hung up unexpectedly”读取die()。
但是如果连接没有中断，那么最常见的问题是远程的index-pack或unpack-objects抱怨我们的包（我们也可能有本地的pack-objects错误，但结果是一样的;我们会发送一个不完整的包，远程端会抱怨）。
在这种情况下，我们确实从另一边报告了错误（因为第2步），但我们没有进一步说明参考。
这个问题有两个方面：

• 在步骤1中，“NONE”状态不是“我们看到了一个错误，所以我们没有状态”。

这通常意味着“这个裁判不符合我们的裁判规格，所以我们没有试图推动它”。所以当我们打印出推送状态表时，我们根本不会提到任何refs！
但是即使我们有一个“pack-objects error”的状态枚举，我们也不想盲目地为每个ref设置它。例如，在非原子推送中，我们可能已经拒绝了客户端上已经存在的一些引用（例如：例如，REF_STATUS_REJECT_NODELETE），我们希望报告该情况。

• 在步骤2中，我们只读取解包状态。

但是receive-pack也会告诉我们每个引用（通常是因为解包错误而拒绝它们）。
因此，更好的策略是保留ref status字段（通常为EXPECTING_REPORT)），然后实际接收（并打印）完整的per-ref状态。
这个案例实际上包含在测试套件中，如t5504。8，其写入将被远程解包对象拒绝的包。
但很淫荡。因为我们的包很小，所以大多数时候pack-objects会在远程拒绝它之前写完整的东西，所以它会返回成功，我们会从远程打印出错误。
但偶尔（或者在--stress下运行时），它会慢到可以看到写入失败，而git push不会向refs报告任何内容。
有了这个补丁，测试应该表现一致。
这种方法不应该有任何负面影响。

• 如果我们真的看到了连接断开，那么我们在receive_unpack_status()中已经死了，我们将继续这样做。
• 如果连接在我们得到解包状态后，但在我们看到任何引用状态之前断开，我们仍然会打印远程解包器错误，但现在会说“remote end hung up”而不是返回错误。

但正如所讨论的，我们没有展示任何比当前代码更有用的东西。无论如何，这种情况是不太可能发生的（由于事件的顺序，此时断开的连接必须与pack-objects错误无关）。
在将来，我们可能希望自己处理数据包读取错误，而不是死，这将打印一个完整的引用状态表，即使是挂起。
但在此期间，这个补丁应该是一个严格的改进。

我在上传千兆字节的数据到github仓库时遇到了同样的问题。增加HTTP缓冲区大小对这种大小的数据不起作用。我不知道这是Git本身的问题还是Github服务器的问题。无论如何，我做了一个shell脚本来处理这个问题，它一步一步地上传当前目录中的文件，每一步都少于100 MB的数据。它对我来说工作很好。这需要时间，但我可以只分离屏幕，等待一夜。
下面是shell脚本：https://gist.github.com/sekika/570495bd0627acff6c836de18e78f6fd

我不知道为什么，但我有这个问题，当我从“5G”版本的wifi网络切换到另一个时，它就消失了

我在使用GitLab托管的私有仓库时遇到了这个问题。这个问题是由于一次提交太多数据造成的。
我使用git reset --soft +相关标识符修复了这个问题，如https://stackoverflow.com/a/2846154/9731176所述。