快速的解决方案:

对于这种错误，我通常通过提高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.

http。postBuffer的把戏对我没用。然而:

对于遇到此问题的其他人，这可能是GnuTLS的问题。如果您设置了Verbose模式，您可能会看到下面代码行所示的基本错误。

不幸的是，到目前为止我唯一的解决方案是使用SSH。

我在其他地方看到过用OpenSSL而不是GnuTLS编译Git的解决方案。这里有一个针对该问题的活动错误报告。

GIT_CURL_VERBOSE=1 git clone https://github.com/django/django.git

Cloning into 'django'...
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * Connected to github.com (192.30.252.131) port 443 (#0)
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> GET /django/django.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept: */*
Accept-Encoding: gzip

Pragma: no-cache
< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:14 GMT

< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
* Connection #0 to host github.com left intact
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * connected
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL re-using session ID
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> POST /django/django.git/git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept-Encoding: gzip

Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Encoding: gzip
Content-Length: 2299
* upload completely sent off: 2299out of 2299 bytes

< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:15 GMT

< Content-Type: application/x-git-upload-pack-result
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
remote: Counting objects: 232015, done.
remote: Compressing objects: 100% (65437/65437), done.
* GnuTLS recv error (-9): A TLS packet with unexpected length was received.
* Closing connection #0
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

它可能像服务器问题一样简单。如果使用GitHub，请检查https://twitter.com/githubstatus。我刚刚第一次看到这个，发现GitHub有一个摆动。几分钟后，它又正常工作了。

奥林匹克广播服务公司。:修改http。postBuffer可能还需要设置Nginx配置文件，让gitlab通过调优client_max_body_size的值来接受更大的客户端尺寸。

然而，如果你可以访问Gitlab机器或其网络中的机器，就有一个解决方案，那就是使用git bundle。

转到源计算机上的git存储库 运行git bundle create my-repo。包——所有 (如转移。， rsync) my-repo。绑定文件到目标计算机 在目标机器上，运行git clone my-repo.bundle Git远程地址:path/to/your/repo.git git推

祝你一切顺利!

我也遇到过类似的问题，不过是竹子做的活。竹是失败的做本地克隆(本地但通过SSH代理)缓存的存储库，我删除了缓存，之后它工作了，但任何时候它试图从本地缓存克隆有一个失败。似乎是bamboo的SSH代理版本的问题，而不是git本身。

这对我来说很有效，设置谷歌的命名服务器，因为没有指定标准的命名服务器，然后重新启动网络:

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0

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

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

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

在/etc/resolv.conf中，将这一行添加到文件的末尾

options single-request

使用以下命令后，我得到了解决方案:

Git重新打包-a -f -d——window=250——depth=250

检查网速。同时检查以下命令:

$ git config --global http.postBuffer 2M
$ git pull origin master

嗯，我想推出一个219 MB的解决方案，但我没有运气

git config --global http.postBuffer 524288000

有一个525mb的后缓冲区有什么意义呢?这是愚蠢的。所以我查看了下面的git错误:

Total 993 (delta 230), reused 0 (delta 0)
POST git-receive-pack (5173245 bytes)
error: fatal: RPC failed; curl 56 SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054

git想要发布5mb，然后我将post buffer设为6mb，它可以工作

git config --global http.postBuffer 6291456

I was doing git push from my OS X El Capitan Mac. I was getting same error, I tried everything to fix, what I found on google/stackoverflow. As far as version is concerned I am using fairly latest version of github which is 2.7.4. I have create a project in my local system, and I wanted this to be public in my github account. Project size was not around 8MB. I noticed that when I was pushing some files of size around 1.5MB, it was pushing properly, but with large size failed for me, with same error,

我唯一的选择是在MB块中推送更改。现在我已经推送了所有更改。这是我的工作，直到我得到这个解决方案。

因此，您也可以尝试在多次提交中推动更改。或者如果你有多个文件夹，你可以按每个文件夹推送更改(如果文件夹大小不大)。

希望这将有助于你继续工作的项目。

对我来说唯一有效的方法是使用HTTPS链接而不是SSH链接克隆回购。

我发现我的问题是与.netrc文件，如果是这样，那么你也可以做以下:

打开你的.netrc文件并编辑它以包含github凭证。 输入nano ~/netrc或gedit ~/netrc

然后包括以下内容: *机器github.com

登录用户名

密码的秘密

机器api.github.com

登录用户名

密码的秘密*

你可以在那里包括你的原始密码，但出于安全考虑，在这里生成一个认证令牌github令牌，并粘贴它在你的密码的地方。

希望这对大家有所帮助

我也有同样的问题。这个问题的原因正如Kurtis对GNUTLS的描述。

如果你有同样的原因，并且你的系统是Ubuntu，你可以通过从ppa安装最新版本的git来解决这个问题:git-core/ppa。命令如下所示。

sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get git

如果你正在使用https，你会得到错误。

我使用https而不是http，它解决了我的问题

git config --global https.postBuffer 524288000

我有同样的错误，而使用BitBucket。我所做的是从我的回购的URL中删除https，并使用HTTP设置URL。

git remote set-url origin http://mj@bitbucket.org/mj/pt.git

当我从由elastic beanstalk管理的AWS EC2实例上托管的远程git repo克隆数据(通过HTTP)时，我就遇到了这个问题。 克隆本身也是在AWS EC2实例上完成的。

我尝试了上述所有的解决方案以及它们的组合:

setting git's http.postBuffer settinghttp.maxrequestbuffer turning off git compression and trying "shallow" git clone and then git fetch --unshallow - see fatal: early EOF fatal: index-pack failed tunning GIT memory settings - packedGitLimit et al, see here: fatal: early EOF fatal: index-pack failed tunning nginx configuration - setting client_max_body_size to both big value and 0 (unlimited); setting proxy_request_buffering off; setting options single-request in /etc/resolv.conf throttling git client throughput with trickle using strace for tracing git clone considering update of git client

在所有这些之后，我仍然一次又一次地面临同样的问题，直到我发现这个问题是在弹性负载均衡器(ELB)切断连接。 在直接访问EC2实例(一个托管git repo)而不是通过ELB之后，我终于成功克隆了git repo! 我仍然不确定是哪个ELB(超时)参数导致了这一点，所以我仍然需要做一些研究。

更新

改变AWS弹性负载均衡器的连接耗尽策略，将超时时间从20秒提高到300秒，似乎为我们解决了这个问题。

git克隆错误和“连接耗尽”之间的关系很奇怪，对我们来说并不明显。可能是连接耗尽超时更改导致ELB配置中的一些内部更改，从而修复了过早关闭连接的问题。

这是AWS论坛上的相关问题(还没有答案):https://forums.aws.amazon.com/thread.jspa?threadID=258572

我也有同样的问题，这与互联网连接不好有关，所以在尝试了一些git配置后，我刚刚断开了我的网络，并再次连接，它工作了!

似乎在连接丢失(或触发此情况的操作)后，git被卡住了。

我希望这能对更多的人有所帮助。

最好的

Bitbucket也有同样的错误。固定的

git config --global http.postBuffer 500M
git config --global http.maxRequestBuffer 100M
git config --global core.compression 0

这可能是因为提交的大小。按以下步骤分解提交的数量:

git log -5

查看最后5次提交，您就会知道哪些没有被推送到远程。 选择一个提交id，并将所有提交推到该id:

git push <remote_name> <commit_id>:<branch_name>

注意:我刚刚检查了我的提交，可以有最大的大小;第一次推到那时。这个把戏成功了!!

我也有同样的问题， 我用试错法解决了这个问题。我改变了core。compression值直到它生效。

在3次尝试后，我从“git配置-global core.compression 1”开始

“git config—global core.compression 4”对我很有用。

解决WIFI路由器设置:

当我在wifi设置PPPoE(通过wifi路由器自动登录)时，我也遇到了同样的问题。

Git下载速度非常慢15kb。

packet_write_wait: Connection to 17.121.133.16 port 22: Broken pipe 致命的:对端意外挂机 致命:早期EOF 致命:索引包失败

解决方案: 1. 更改设置为动态IP，重新启动wifi路由器。 2. 从web浏览器登录到Internet服务提供商门户(不配置PPPoE，从wifi路由器自动登录)。

修改后的Git下载速度为1.7MiB。

这是由于网络连接问题，我也遇到过同样的问题。 我做了一个浅层的代码副本使用

git clone --depth 1 //FORKLOCATION

稍后取消浅化克隆使用

git fetch --unshallow

面对同样的问题，试着与另一个分支合并，并从他们那里吸取教训。 对我来说也一样。

使用SSH而不是http，这不是这个问题的一个好答案，但至少它对我有用

基于这个答案，我尝试如下(使用https url):

repo初始克隆:

Git克隆——深度为25的url-here

Fetch每次尝试深度增加两次提交:

Git取回——深度50

Git取回——深度为100

Git取回深度200

.．.等等

最终(当我认为足够的获取)，我运行git fetch -unshallow -它就完成了。

这个过程显然需要更多的时间，但在我的情况下设置http。postBuffer和core.compression没有帮助。

UPD:我发现通过ssh获取适用于任何回购大小(偶然发现)，用git clone <ssh url>完成，前提是你已经创建了ssh密钥。一旦repo获取，我改变远程地址使用git远程set-url <https url repo>

我也有同样的问题，正在网上搜索解决方案。我发现我们公司的IPv6路由没有维护。

我关闭了(在Windows 10的以太网端口上的IPv6选项)，没有问题。

当我通过ssh克隆存储库时，建议的解决方案都不适用。然而，我能够使用https克隆，然后后来将远程更改为ssh通过:

git remote set-url origin git@github.com:USERNAME/REPOSITORY.git

这解决了我的问题:

git clone --depth=20 https://repo.git -b master

上面的技巧对我没有帮助，因为repo比github允许的最大推送大小还要大。有效的方法是来自https://github.com/git-lfs/git-lfs/issues/3758的建议，建议每次推一点:

If your branch has a long history, you can try pushing a smaller number of commits at a time (say, 2000) with something like this: git rev-list --reverse master | ruby -ne 'i ||= 0; i += 1; puts $_ if i % 2000 == 0' | xargs -I{} git push origin +{}:refs/heads/master That will walk through the history of master, pushing objects 2000 at a time. (You can, of course, substitute a different branch in both places if you like.) When that's done, you should be able to push master one final time, and things should be up to date. If 2000 is too many and you hit the problem again, you can adjust the number so it's smaller.

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

对于共享带宽，尝试在负载较小时进行克隆。否则，请尝试高速连接。如果仍然不工作，请使用以下命令，

git config --global http.postBuffer 2048M
git config --global http.maxRequestBuffer 1024M
git config --global core.compression 9

git config --global ssh.postBuffer 2048M
git config --global ssh.maxRequestBuffer 1024M

git config --global pack.windowMemory 256m 
git config --global pack.packSizeLimit 256m

再试着克隆一次。您可能需要根据可用内存大小更改这些设置。

在MacOSX High Sierra游戏中，我的解决方案是:

brew install git-lfs

我的存储库被克隆了，没有任何错误。

浪费了几个小时尝试这些解决方案，但最终追踪到公司IPS(仪器保护系统)在传输一定量的数据后断开了连接。

增加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.等待克隆完成。

谢谢你！快乐编码!!

唯一对我有用的是:

克隆浅: Git克隆<yourrepo>—深度10 编辑。git/config如下:

之前

[remote "origin"]
    fetch = +refs/heads/master:refs/remotes/origin/master

后

[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*

Git配置——global http。maxRequestBuffer 100 Git配置——global core.compression 0 Git获取

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

将克隆屏幕中的源树高级选项的深度更改为25对我来说很有效

运行git push…从Mac终端做出的技巧，这是不同的尝试从IDE(我的情况:VSCode)导致的问题。

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

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

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

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

使用SSH:

如果您将postBuffer增加到524288000 (500mb)， 1048576000 (1GB)和2147483648 (2GB)，但问题没有解决，我的建议是使用SSH克隆或拉出存储库。生成SSH密钥对

我把它改成了SSH地址，一切都恢复了正常工作。