git clone报错RPC failed； curl 18 transfer closed with outstanding read data remaining

问题

拉取码云代码时报错RPC failed; curl 18 transfer closed with outstanding read data remaining

排查

通过查看文件大小，是项目下面的.git太大了

描述

我们使用过 Git 的同学都知道，随着代码的更新迭代，仓库的体积越来越大。如果操作和使用都比较恰当的情况下，仓库体积不会突增的。但是如果使用不恰当的话，那就非常尴尬了，比如我们下面要说的这种情况，.git 这个隐藏目录特别大。

虽然 .git 这个隐藏目录并不算在代码体积之后，但是我们拉代码的时候，是需要拉下来的，因为里面包含之前的提交记录等信息。这就会导致，原本平和的心情变得焦躁了，因为下载速度变的很慢。

原因解释

当我们使用 git add 和 git commit 命令的过程中，Git 不知不觉就会帮我们创建出来了 blob 文件对象，然后更新 index 索引，再然后创建 tree 对象，最后创建出了 commit 对象。这些 commit 对象指向了顶层 tree 对象以及先前的 commit 对象。

而上述创建出来的对象，都以文件的方式保存在 .git/objects 目录下。所以，当我们在使用的过程中，提交了一个体积特别大的文件，就会被 Git 追踪记录在 .git/objects 文件夹下面。

此时，如果我们再次删除这个体积特别大的文件，其实 Git 只会记录了我们删除的这个操作，但并不会把文件从 .git 文件夹下面真正的删除，即 .git 文件夹完全不会变小。

解决方法

https://blog.csdn.net/lilizhou2008/article/details/123038737

解决

一、

设置postBuffer大小，git config --global http.postBuffer 2097152000结果并没有用

因后来clone成功没尝试后面方式

二、

先浅层clone,只会拉取最近的一次提交，浅层clone成功后，再完整拉取
2.1. 先浅层clone,只会拉取最近的一次提交

$ git clone --depth=1 http://xxx.git    

2.2. 浅层clone成功后，再完整拉取：

1） 先转换存储库为完整存储库，消除浅层存储库所施加的所有限制。
    $ git fetch --unshallow 
2） 命令修改.git文件夹内config文件的[remote "origin"]节的内容
    $ git remote set-branches origin '*'

#若命令无法修改，可直接修改.git文件夹内config文件的[remote "origin"]节的内容
修改前
[remote "origin"]
    url = https://xxx.com/abc/xxx.git
    fetch = +refs/heads/master:refs/remotes/origin/master
修改后
[remote "origin"]
    url = https://xxx.com/abc/xxx.git
    fetch = +refs/heads/*:refs/remotes/origin/*
以上步骤也可用命令代替
git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"

3.然后执行以下命令获取所有分支

git fetch -pv 或 $ git fetch -v