增加postBuffer大小和maxRequestBuffer将有助于解决这个问题。按照步骤做就可以了。

步骤:

1 .打开终端或Git Bash，用“cd”转到你想克隆repo的位置。

2.将压缩设置为0

git config --global core.compression 0

3.设置postBuffer大小

git config --global http.postBuffer 1048576000

4.设置maxRequestBuffer大小

git config --global http.maxRequestBuffer 100M

5.现在开始克隆

git clone <repo url>

6.等待克隆完成。

谢谢你！快乐编码!!

对我来说，问题是安装在MacOS上的诺顿安全。一旦我临时禁用防火墙和其他诺顿保护，我的git推送工作正常。

快速的解决方案:

对于这种错误，我通常通过提高postBuffer大小开始:

git config --global http.postBuffer 524288000

(下面的一些评论报告称，该值必须翻倍):

git config --global http.postBuffer 1048576000

(对于npm发布，Martin Braun在评论中报告，将其设置为不超过5 000 000，而不是默认的1 000 000)

# # #更多信息:

从git配置手册页，http。postBuffer是关于:

智能HTTP传输在向远程系统发送数据时使用的缓冲区的最大字节大小。 对于大于这个缓冲区大小的请求，使用HTTP/1.1和Transfer-Encoding: chunked来避免在本地创建一个庞大的包文件。缺省值为1mib，满足大多数请求。

即使对于克隆来说，这也会产生影响，在这种情况下，OP Joe报告说:

[克隆]现在工作正常

注意:如果服务器端出现错误，并且服务器使用Git 2.5+ (Q2 2015)，错误消息可能会更加明确。 参见“Git克隆:远程端意外挂起，尝试更改postBuffer但仍然失败”。

Kulai(在评论中)指出了这个Atlassian故障排除Git页面，它补充道:

错误代码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邮件列表讨论)

文档:在增加http时提到。postBuffer很有价值 署名:布莱恩·m·卡尔森

Users in a wide variety of situations find themselves with HTTP push problems. Oftentimes these issues are due to antivirus software, filtering proxies, or other man-in-the-middle situations; other times, they are due to simple unreliability of the network. However, a common solution to HTTP push problems found online is to increase http.postBuffer. This works for none of the aforementioned situations and is only useful in a small, highly restricted number of cases: essentially, when the connection does not properly support HTTP/1.1. Document when raising this value is appropriate and what it actually does, and discourage people from using it as a general solution for push problems, since it is not effective there.

git配置http的文档。postBuffer现在包括:

http.postBuffer

Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system. For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which issufficient for most requests. Note that raising this limit is only effective for disabling chunked transfer encoding and therefore should be used only where the remote server or a proxy only supports HTTP/1.0 or is noncompliant with the HTTP standard. Raising this is not, in general, an effective solution for most push problems, but can increase memory consumption significantly since the entire buffer is allocated even for small pushes.

我的经验是，这肯定是某个地方的连接超时。

最终，我在电脑上插入了一个蹩脚的wifi适配器，并使用了手机的热点。

当我使用有线连接到我的ISP时，向Github上传一个小更改是可以的，所以连接和身份验证在原则上是有效的。 但是当尝试推送一个新的80Mb存储库时，出现了错误。

在设法通过wifi加密狗/热点推动回购后，小的增量变化很好。

我必须删除git clone命令的分支标志。

我在Kubuntu使用git时遇到了这个问题。我还注意到网络的整体不稳定，并找到了解决方案。

在/etc/resolv.conf 将该行添加到文件的末尾 选择单请求

这固定延迟之前，每个域名解析和git开始工作像一个魅力之后。