Git Clone 卡在 Receiving Objects 问题排查总结

Git Clone 卡在 Receiving Objects 问题排查总结

问题现象

执行下面的命令时，仓库一直拉不下来：

git clone git@codeup.aliyun.com:681b03a181f0d609ac6a37d3/Frontend/FrontDesk.git

终端输出大致停在这里：

Cloning into 'FrontDesk'...
remote: Enumerating objects: 12123, done.
remote: Counting objects: 100% (3942/3942), done.
Receiving objects: 12% (1455/12123)

已知条件：

• 别的电脑可以正常克隆同一个仓库
• 当前这台电脑一直卡住
• 远程地址本身没有问题

关键判断

这类问题不能只看“能不能连上远程”，要区分是哪一层出问题：

1. SSH 登录是否正常
2. 仓库元数据是否可读
3. 实际对象传输是否正常
4. 本机 Git 调用的是哪个 SSH 客户端

Receiving objects 卡住，说明已经不是“地址写错”或“完全连不上”这类问题了。Git 已经连到远端，并且远端也开始返回数据。问题更可能出在对象传输链路或本机环境。

这次排查的过程

1. 先确认 SSH 连通和认证

执行：

ssh -T git@codeup.aliyun.com

结果正常，说明：

• SSH key 没问题
• 账号权限没问题
• 基本网络连通没问题

2. 再确认仓库远端可读

执行：

git ls-remote git@codeup.aliyun.com:681b03a181f0d609ac6a37d3/Frontend/FrontDesk.git

结果也正常，说明：

• 仓库地址没问题
• 访问权限没问题
• Git 读取远端引用正常

这一步非常关键。它能证明问题不在“仓库不存在”或者“没有权限”。

3. 做一次浅克隆验证

执行：

git clone --depth 1 --single-branch --branch master --progress git@codeup.aliyun.com:681b03a181f0d609ac6a37d3/Frontend/FrontDesk.git FrontDesk_probe

结果仍然卡住。

这说明问题不只是“仓库历史太大”。

4. 检查卡住时本地 .git 的状态

发现浅克隆留下的临时 pack 文件是 0 字节，说明不是慢慢在下载，而是传输链路根本没有正常往下走。

这一步的经验是：

• 如果 pack 文件在持续增长，多半是慢
• 如果 pack 文件长期是 0 字节，更像是传输流程卡死

5. 查 Git 实际调用的 SSH 客户端

表面上直接执行 ssh 时，系统使用的是：

C:\Windows\System32\OpenSSH\ssh.exe

但 git clone 实际调用的是：

D:\Git\usr\bin\ssh.exe

这就是问题的核心。

也就是说：

• 命令行里手动跑 ssh，走的是系统 OpenSSH
• Git 内部发起 clone 时，走的是 Git for Windows 自带的 ssh.exe

这两个不是同一个程序。

根因

根因不是仓库地址错误，也不是远程权限问题，而是：

当前电脑上的 Git 在 clone 时默认使用了 D:\Git\usr\bin\ssh.exe，这个 SSH 客户端在该环境下的大对象传输阶段会卡住。

而系统自带的 OpenSSH 没有这个问题。

解决方案

把 Git 全局配置改为使用系统 OpenSSH：

git config --global core.sshCommand C:/Windows/System32/OpenSSH/ssh.exe

配置完成后，再执行原始 clone 命令即可正常完成：

git clone git@codeup.aliyun.com:681b03a181f0d609ac6a37d3/Frontend/FrontDesk.git

也可以只对单次命令临时生效：

git -c core.sshCommand=C:/Windows/System32/OpenSSH/ssh.exe clone git@codeup.aliyun.com:681b03a181f0d609ac6a37d3/Frontend/FrontDesk.git

为什么这个方案有效

因为这次问题不在仓库、不在权限，而在本机 Git 选用的 SSH 客户端。

强制指定系统 OpenSSH 之后：

• 远端认证正常
• 对象传输正常
• 完整 clone 正常完成

所以这是一个典型的“本机环境差异”问题，而不是“仓库有问题”。

以后遇到类似问题的排查顺序

建议固定用下面的顺序判断：

第一步：测 SSH 登录

ssh -T git@codeup.aliyun.com

如果这一步失败，优先排查：

• SSH key
• known_hosts
• 网络
• 防火墙

第二步：测仓库远端读取

git ls-remote git@codeup.aliyun.com:681b03a181f0d609ac6a37d3/Frontend/FrontDesk.git

如果这一步失败，优先排查：

• 仓库路径
• 仓库权限
• Git 协议配置

第三步：测浅克隆

git clone --depth 1 --single-branch git@codeup.aliyun.com:681b03a181f0d609ac6a37d3/Frontend/FrontDesk.git

如果浅克隆都卡住，说明：

• 不是单纯历史太大
• 更可能是本机传输链路、SSH 客户端、代理、防病毒软件或磁盘写入问题

第四步：确认 Git 用的是哪个 SSH

重点不要只看：

where ssh

因为这只能看到命令行默认的 ssh，不一定是 Git 实际调用的那个。

要结合 Git 配置和实际进程一起看，确认 clone 时到底用的是哪一个 ssh.exe。

这次问题里最重要的经验

经验 1

Receiving objects 卡住，不代表路径错了。

如果已经走到这一步，通常说明：

• 远程地址基本是对的
• 认证大概率已经通过
• 问题更偏向传输或本机环境

经验 2

“别的电脑可以，这台不行”，优先怀疑本机环境差异。

比如：

• Git 版本不同
• SSH 客户端不同
• 代理不同
• 杀毒或安全软件不同
• 系统策略不同

经验 3

ssh -T 成功，不代表 git clone 一定正常。

因为：

• ssh -T 只说明登录测试成功
• git clone 还涉及 git-upload-pack、pack 传输、index-pack 等完整流程

经验 4

Windows 上经常会出现“你以为 Git 用的是这个 ssh，实际上用的是另一个 ssh”的情况。

这是这次问题最值得记住的一点。

可直接复用的处理办法

以后如果再遇到类似现象，可以先直接试：

git -c core.sshCommand=C:/Windows/System32/OpenSSH/ssh.exe clone <repo>

如果这样能成功，再决定是否写入全局配置：

git config --global core.sshCommand C:/Windows/System32/OpenSSH/ssh.exe

一句话总结

这次问题的本质是：

仓库没问题，权限没问题，真正有问题的是当前机器上 Git 默认调用的 SSH 客户端。把 Git 切到系统 OpenSSH 后，clone 立即恢复正常。