在我的例子中，问题不在于git配置参数，而是我的存储库中有一个文件超过了系统允许的最大文件大小。我能够检查它试图下载一个大文件，并得到一个“文件大小限制超过”在Debian上。

之后，我编辑了我的/etc/security/limits.conf文件，在它的末尾添加了以下几行:

硬fsize 1000000 软fsize 1000000

要真正“应用”新的限制值，您需要重新登录

最终通过git配置——global core.compression解决

来自BitBucket问题线程:

我试了差不多五次，还是会这样。 然后我尝试使用更好的压缩，它工作! Git配置——global core.compression

从Git文档:

core.compression 整数-1..9，表示默认压缩 的水平。-1是zlib的默认值。 0表示不压缩，1..9是 各种速度/大小的权衡，9是最慢的。 如果设置，这将提供一个 默认为其他压缩变量，如core.looseCompression 和pack.compression。

在我的情况下，当协议是https时，什么都不起作用，然后我切换到ssh，并确保，我从上次提交而不是整个历史，以及特定的分支中拉回回购。这帮助了我:

Git克隆——深度1 "ssh:。Git "——branch " specific_branch "

只是在这里添加一个提示，如果你的git克隆命令有一个代理参数，你的代理服务器可能会过早地断开你的http/s请求，因为它自己的配置不允许太大的http响应二进制。仅供参考。

我得到了同样的错误， 在我这边，我通过运行这个命令来解决，在windows中它有一些内存问题。

git config --global pack.windowsMemory 256m

网络质量很重要，尽量切换到不同的网络。 帮助我的是把我的互联网连接从维珍媒体(Virgin Media)的高速陆地宽带改为手机上的热点。

在此之前，我尝试了限制克隆大小的公认答案，尝试了在64位和32位版本之间切换，尝试了禁用git文件缓存，没有一个有用。

然后我通过我的手机切换到连接，第一步(git克隆—深度1 <repo_URI>)成功了。切换回我的宽带，但下一步(git fetch -unshallow)也失败了。所以我删除了到目前为止克隆的代码，切换到移动网络，再次尝试默认方式(git clone <repo_URI>)，它成功了，没有任何问题。