Git 如何在不稳定网络下续传大型仓库的克隆？

2026-11-06数据小许

结论

Git 没有通用的 git clone 选项，能在任意远程仓库的传输中断后，从中断位置继续下载同一个 pack。普通 git clone 失败后，通常无法接着下载未完成的 pack。调整压缩或 HTTP 缓冲区参数也不能让它支持断点续传。

如果想减少初次下载量，可以使用 partial clone 延迟获取文件内容，再配合 sparse checkout 只检出需要的路径。这样能减少实际下载的数据，但不能实现完整仓库的断点续传。

延迟下载文件内容

对于 GitHub 上支持过滤式克隆的仓库，可以尝试：

git clone --filter=blob:none --no-checkout https://github.com/cyizhuo/FGVC_Aircraft_dataset.git
cd FGVC_Aircraft_dataset
git sparse-checkout init --cone
git sparse-checkout set path/to/needed-directory
git checkout

--filter=blob:none 会请求 Git 先获取提交和目录树信息，等需要时再下载文件内容（blobs）。sparse-checkout 则限制工作区中检出的目录，适合只需要仓库部分文件的情况。将 path/to/needed-directory 换成实际路径即可；如果所需文件分布在多个目录，可以把多个路径传给 git sparse-checkout set。

实际效果取决于服务器是否支持过滤式克隆，也取决于仓库的对象和目录结构。首次克隆仍需获取所需的提交和树对象；之后如果读取了大量文件，Git 也会下载相应内容。

网络中断时重试

如果克隆后留下了可用的本地仓库目录，可以在其中尝试重新获取远端数据：

cd FGVC_Aircraft_dataset
git fetch origin

如果失败后没有留下可用的 .git 仓库，就需要重新初始化并配置远端，或者重新克隆。重试时可能会复用已成功写入本地的对象，但通常无法从字节位置接着传输尚未完成的 pack。因此，重试不能保证省下已经传输的数据。脚本可以自动重试失败的命令，但这不代表支持断点续传。

参数说明

问题中列出的 core.compression、http.postBuffer 和 http.maxRequestBuffer 设置，都不会让 git clone 支持续传。尤其是 http.postBuffer，主要用于 HTTP 推送请求，无法恢复中断的克隆传输。没有明确诊断依据时，不建议为了续传而全局修改这些配置。

如果必须获取完整仓库，并且传输必须支持按字节续传，就需要借助支持续传的中间存储或传输服务。Git 客户端的常规克隆协议不提供通用的续传保证。归档下载可能更适合获取某个快照，但通常不包含完整 Git 历史，也不能代替克隆仓库。