快速解决方案：
遇到这种错误，我通常首先将postBuffer 的大小提高：
git config --global http.postBuffer 524288000
（下面的一些 cmets 报告必须将值加倍）：
git config --global http.postBuffer 1048576000
（对于npm publish，Martin Braun 报告 in the comments 将其设置为不超过 50 000 000 而不是默认的 1 000 000）
###更多信息：
来自git config man page，http.postBuffer是关于：
将数据发送到远程系统时，智能 HTTP 传输使用的缓冲区的最大大小（以字节为单位）。
对于大于这个缓冲区大小的请求，使用 HTTP/1.1 和Transfer-Encoding: chunked 来避免在本地创建大量的包文件。默认为 1 MiB，足以满足大多数请求。
即使是克隆，也会产生影响，在这种情况下，OP Joe 报告：
[克隆] 现在可以正常工作了
注意：如果服务器端出现问题，并且服务器使用 Git 2.5+（2015 年第二季度），则错误消息可能会更明确。
见“Git cloning: remote end hung up unexpectedly, tried changing postBuffer but still failing”。
Kulai (in the comments) 指向this Atlassian Troubleshooting Git page，它补充说：
Error code 56 表示 curl 收到 CURLE_RECV_ERROR 的错误，这意味着在克隆过程中存在一些问题，导致无法接收数据。
这通常是由网络设置、防火墙、VPN 客户端或防病毒软件在传输所有数据之前终止连接造成的。
它还提到了以下环境变量，以帮助调试过程。
# Linux
export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1
#Windows
set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1
使用 Git 2.25.1（2020 年 2 月），您会更了解这个 http.postBuffer“解决方案”。
参见brian m. carlson (bk2204) 的commit 7a2dc95、commit 1b13e90（2020 年 1 月 22 日）。
（由 Junio C Hamano -- gitster -- 合并到 commit 53a8329，2020 年 1 月 30 日）
(Git Mailing list discussion)
docs: 增加 http.postBuffer 时提及是有价值的
签字人：brian m.卡尔森
各种情况下的用户都会发现自己遇到 HTTP 推送问题。
这些问题通常是由防病毒软件、过滤代理或其他中间人情况引起的；其他时候，它们是由于网络的简单不可靠性。
不过，网上发现的 HTTP 推送问题的常见解决方法是增加 http.postBuffer。
这不适用于上述任何情况，仅在极少数情况下有用：本质上，当连接不正确支持 HTTP/1.1 时。
记录何时提高此值是适当的以及它实际上做了什么，并劝阻人们不要将其用作推送问题的通用解决方案，因为它在那里无效。
所以git config http.postBuffer 的文档现在包括：
http.postBuffer
将数据发送到远程系统时，智能 HTTP 传输使用的缓冲区的最大大小（以字节为单位）。
对于大于此缓冲区大小的请求，使用 HTTP/1.1 和 Transfer-Encoding: chunked 来避免在本地创建海量包文件。
默认为 1 MiB，这对于大多数请求来说已经足够了。
请注意，提高此限制仅对禁用分块传输编码有效，因此仅应在远程服务器或代理仅支持 HTTP/1.0 或不符合 HTTP 标准的情况下使用。
提高此限制一般来说，对于大多数推送问题来说，这不是一个有效的解决方案，但会显着增加内存消耗，因为即使是小推送也会分配整个缓冲区。