这些对我来说都没用，但使用Heroku的内置工具却奏效了。

heroku git:clone -a myapp

文档在这里:https://devcenter.heroku.com/articles/git-clone-heroku-app

请注意，Git 2.13.x/2.14(2017年第三季度)确实引发了默认核心。影响git取回的packedGitLimit: 在较大的平台上，默认的package -git限制值已经提高(从8 GiB提高到32 GiB)，以避免“gc”并行运行时“git获取”(可恢复的)失败。

参见David Turner (csusbdt)的commit be4ca29(2017年4月20日)。 帮助:Jeff King (peff)。 (由Junio C Hamano—gitster—在commit d97141b中合并，2017年5月16日)

Increase core.packedGitLimit When core.packedGitLimit is exceeded, git will close packs. If there is a repack operation going on in parallel with a fetch, the fetch might open a pack, and then be forced to close it due to packedGitLimit being hit. The repack could then delete the pack out from under the fetch, causing the fetch to fail. Increase core.packedGitLimit's default value to prevent this. On current 64-bit x86_64 machines, 48 bits of address space are available. It appears that 64-bit ARM machines have no standard amount of address space (that is, it varies by manufacturer), and IA64 and POWER machines have the full 64 bits. So 48 bits is the only limit that we can reasonably care about. We reserve a few bits of the 48-bit address space for the kernel's use (this is not strictly necessary, but it's better to be safe), and use up to the remaining 45. No git repository will be anywhere near this large any time soon, so this should prevent the failure.

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

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

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

来自BitBucket问题线程:

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

从Git文档:

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

在我的情况下，这是一个连接问题。我连接到一个内部wifi网络，在这个网络中，我只能访问有限的资源。这是让git进行取回，但在某个时间它崩溃了。 这意味着它可能是网络连接问题。检查是否一切运行正常:防病毒，防火墙等。

因此，elin3t的答案很重要，因为ssh提高了下载的性能，从而可以避免网络问题

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