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

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

上面的技巧对我没有帮助，因为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.

奥林匹克广播服务公司。:修改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推

祝你一切顺利!

快速的解决方案:

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

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

git log -5

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

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

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

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