Windows
macOS
Android
iOS
开发者远程仓库拉取提速，首先要确认慢在哪里：是域名解析耗时、连接不稳定、对象下载缓慢，还是检出阶段消耗时间。以 GitHub、GitLab.com 或 Bitbucket 上的项目为例，直接更换代理并不一定有效；全局代理残留、HTTPS 与 SSH 路径不一致、子模块或 Git LFS 文件过大，都可能让“加速”变成新的故障来源。
先把拉取过程拆开测量
一次仓库拉取通常包含域名解析、建立连接、身份认证、下载对象、处理子模块和工作区检出。建议使用同一台机器、同一网络、同一仓库进行三次测试，并分别记录总耗时、下载阶段耗时和失败信息。第一次测试可能受本地磁盘缓存影响，因此不要只看单次结果。
| 现象 | 更可能的原因 | 优先检查项 |
|---|---|---|
| 开始连接就超时 | 网络路径、DNS 或代理不可达 | 解析结果、代理端口、出口网络 |
| 连接成功但下载速度波动 | 跨网链路拥塞或代理转发不稳定 | 同一时间的直连与代理对比 |
| 下载完成后仍很慢 | 对象数量多、子模块或磁盘性能不足 | 仓库历史、子模块、磁盘占用 |
| 只有某个项目失败 | 权限、LFS 或仓库自身配置 | 凭据、访问范围和仓库说明 |
代理误配是最常见的反效果来源
检查三层 Git 配置
Git 可能同时读取系统级、用户级和仓库级配置。用户级配置中留下的旧代理，会影响所有项目；仓库级配置则可能只让某个项目异常。检查 Git 配置界面或配置文件时，重点查看 HTTP、HTTPS 代理以及特定域名的例外规则，避免同一请求被系统代理和应用代理重复转发。
还要检查 HTTP_PROXY、HTTPS_PROXY 等环境变量。图形化客户端、IDE 与终端可能使用不同的环境，因此“终端能拉取、IDE 不能拉取”并不矛盾。清理失效代理后，应先用一种路径验证，再逐步恢复其他设置。不要为了提高速度同时开启 VPN、系统代理和 Git 私有代理。
HTTPS 与 SSH 的选择
HTTPS通常更容易通过企业网关和身份管理系统，适合需要统一审计的办公网络；缺点是代理认证、证书检查或凭据缓存可能增加故障点。SSH依赖密钥认证，长期使用较方便，但某些网络会限制相关端口，首次排查也要确认公钥已添加到对应平台。两者没有固定的速度优劣，应在相同网络下分别比较连接稳定性和失败率。
按仓库特征选择提速方法
- 历史不重要时使用浅克隆。在 Git 客户端中选择仅获取最近若干提交，可明显减少首次下载量，适合构建、测试和临时查看代码。需要追溯旧版本、切换任意历史分支或生成完整变更记录时，不宜长期依赖浅克隆。
- 只取需要的目录。支持稀疏检出的客户端可以先获取仓库结构，再选择特定目录。它适合大型单体仓库，但某些构建流程依赖完整目录，使用前应确认依赖关系。
- 单独排查 Git LFS。源代码仓库看似不大，LFS 中的模型、音视频或安装包却可能占用大量流量。若项目不需要这些文件，可按项目规则延后获取；若必须使用，应检查 LFS 端点是否与代码仓库走了不同网络路径。
- 谨慎采用仓库镜像。团队可以在合规前提下维护只读镜像或局部缓存，适合多人频繁拉取同一项目。镜像必须设置同步周期、权限和故障切换规则，并明确它可能落后于上游，不能把未同步的镜像当作实时源。
一套可执行的排查顺序
- 固定一个仓库和测试时间，记录仓库大小、分支数量、子模块及 LFS 使用情况。
- 分别测试直连、单一代理和另一种 Git 传输协议，不要同时改变网络、客户端和认证方式。
- 清理过期的全局代理，确认仓库级配置、环境变量和 IDE 设置没有重复覆盖。
- 对临时构建采用浅克隆或稀疏检出；对日常开发保留完整历史，避免后续补齐数据造成重复下载。
- 连续观察数个工作日，记录失败率、平均耗时和高峰时段表现，再决定是否部署镜像或调整网络出口。
常见问题
为什么开了代理反而更慢？
代理增加了转发和加密环节，若出口拥塞、距离远或与目标平台互联较差，速度可能低于直连。应进行同条件对比，而不是只看代理宣传带宽。
浅克隆会损坏仓库吗？
不会，但它缺少部分历史对象。需要查看旧提交、执行某些合并操作或完整发布时，可能需要补齐历史。
仓库镜像适合所有团队吗？
不适合。项目包含敏感代码、同步要求严格或成员很少时，维护镜像的权限和同步成本可能超过收益。
怎样判断已经实现开发者远程仓库拉取提速？
至少比较同一仓库在相同网络下的多次结果，并同时关注总耗时、失败率、重试次数和后续补数据成本。只有稳定改善而不是偶尔变快，才算有效。
因此，可靠的开发者远程仓库拉取提速应建立在测量、清理误配置和按仓库特征选方案之上，而不是简单叠加代理。先找到瓶颈，再选择协议、浅克隆或可信镜像，通常更容易获得稳定收益。