克隆大型仓库卡住（7%每次就卡住了）

克隆到7%就卡住，核心是大文件传输时网络链路不稳定（SSH 连接因长时间低速率传输被远端/防火墙掐断），且单纯增大缓冲区效果有限，需要针对性优化「传输策略」和「连接保活」，以下是按优先级排序的解决方法：

第一步：先验证 SSH 保活配置是否真的生效（关键！）

你之前可能没正确配置/生效 SSH 保活规则，导致传输到7%时连接超时被重置：

1. 打开 MINGW64 终端，执行以下命令检查 SSH 配置文件：

   # 查看 SSH 配置文件内容（确认 bitbucket.org 规则存在）cat~/.ssh/config

   • 若显示No such file or directory：说明没创建成功，重新执行以下命令创建：

     # 强制创建 SSH 配置文件（覆盖空文件）echo-e"Host bitbucket.org\nHostName bitbucket.org\nUser git\nServerAliveInterval 10\nServerAliveCountMax 20\nTCPKeepAlive yes\nConnectTimeout 300">~/.ssh/config# 设置配置文件权限（必须 600，否则 SSH 会忽略）chmod600~/.ssh/config

   • 若已有内容：确认ServerAliveInterval是10（而非60）—— 7%卡住时传输速率慢，60秒保活间隔太长，改成10秒更频繁发保活包，避免连接被掐断。

2. 测试 SSH 连接是否用了新配置：

   ssh-v git@bitbucket.org# 加 -v 看详细日志

   日志中能看到debug1: Applying options for bitbucket.org说明配置生效。

第二步：优化 Git 传输参数（针对7%卡住的低速传输）

默认的 Git 传输参数会一次性拉取大文件，容易在低速时超时，改成「单线程+小批次+低速率」：

# 1. 全局配置：强制单线程传输（避免多线程占带宽被限流）gitconfig --global core.bigFileThreshold 100kgitconfig --global pack.threads1gitconfig --global fetch.parallel0# 2. 增大缓冲区到 1GB（比之前更大，适配大文件）gitconfig --global http.postBuffer1073741824gitconfig --global ssh.postBuffer1073741824# 3. 关闭 Git 压缩（减少远端解压耗时，避免卡住）gitconfig --global core.compression -1

第三步：核心方案——分段拉取（避开7%卡住的大文件批量传输）

直接克隆会一次性拉取所有对象，7%卡住说明刚好遇到大文件包，改用「先拉极小深度→再逐步加深」的分段方式，把大传输拆成小批次：

# 1. 先创建空仓库，关联远端（避免从头克隆的一次性压力）mkdirnextgen&&cdnextgengitinitgitremoteaddorigin ssh://git@bitbucket.org/suunto/nextgen.git# 2. 先拉深度 1 的「最小快照」（只拉最新提交的元数据，无大文件）gitfetch --depth=1origin master --timeout=600--single-branch# 3. 若步骤2成功，再逐步加深深度（每次拉一点，避免卡住）gitfetch --depth=10origin master --timeout=600gitfetch --depth=50origin master --timeout=600gitfetch --unshallow origin master# 最后拉全量（可选，若只需要浅克隆则跳过）# 4. 检出分支（完成克隆）gitcheckout master

• 若步骤2仍卡在7%：把--depth=1改成--depth=0（仅拉分支信息），再手动拉取文件：

  gitfetch origin master --depth=0--timeout=600gitfetch origin master --depth=1--timeout=600--no-tags# 不加标签，减少传输量

第四步：临时规避——改用「断点续传」式克隆（Windows 专属）

如果上述方法仍卡住，用 Git 的partial-clone特性（只拉取当前需要的文件，跳过大文件批量传输）：

# 启用部分克隆，只拉取工作区文件（跳过历史大对象）gitclone --filter=blob:none --depth=1ssh://git@bitbucket.org/suunto/nextgen.git nextgen

• 若提示--filter不支持：升级 Git 版本（MINGW64 下执行pacman -S git升级）。

第五步：排除本地环境干扰（容易忽略）

1. 关闭 Windows 防火墙/杀毒软件（比如 360、Windows Defender）：
   • 这些软件会扫描 SSH 传输的文件，导致7%时速率骤降甚至卡住；
2. 检查 MINGW64 终端的「缓冲区大小」：
   • 右键终端标题栏 → 选项 → 缓冲区 → 把「行数」调到 10000 以上，避免日志刷屏导致卡顿；
3. 切换磁盘分区：
   • 若 D 盘是机械硬盘，临时克隆到 C 盘（固态硬盘），再移动回去（机械硬盘读写慢会卡住传输）。

第六步：终极兜底——改用 HTTPS + 断点续传工具

如果 SSH 始终卡在7%，换 HTTPS 协议，并使用git-lfs或第三方工具断点续传：

# 1. 用 HTTPS 克隆（避开 SSH 端口限流）gitclone --depth=1https://bitbucket.org/suunto/nextgen.git --timeout=600# 2. 若 HTTPS 也卡住，安装 git-lfs 处理大文件gitlfsinstallgitclone --depth=1https://bitbucket.org/suunto/nextgen.git --progress# --progress 显示详细进度

关键排查点

• 若所有方法都卡在7%：大概率是远端 Bitbucket 服务器对 suunto/nextgen 仓库做了带宽限制，或公司网络对该仓库的 IP 做了限流；
• 临时解决方案：让同事克隆成功后，把仓库文件夹压缩发给你，你本地执行git remote set-url origin ssh://git@bitbucket.org/suunto/nextgen.git重新关联远端，避免自己传输。

进度验证

每一步执行后，用git fetch --progress查看详细进度（会显示具体拉取的对象ID和大小），能精准定位是哪个大文件导致卡住，比如：

gitfetch origin master --depth=1--progress

若显示Receiving objects: 7% (1267/16441), 6.93 MiB | 3.40 MiB/s后不动，说明该批次的第1267个对象是大文件，可针对性跳过：

gitfetch --exclude=refs/tags/* --exclude=refs/heads/* --depth=1origin master# 只拉master分支，排除标签/其他分支

兜底

如果上面所有方法查询了还是不行，就退出git bash，进入nextgen 目录，打开cmd窗口

gitfetch --progress --depth=1origin developgitcheckout develop