Git clone 走了代理，但 Git LFS 失败

在改动一个本来可用的代理之前，把 Git LFS 的元数据与对象下载和 Git clone 分开排查。

克隆可能已经传完 Git 对象，但 LFS 内容仍然缺失。Git 存的是指针文件；LFS 客户端会为这些大对象另外发起请求。

在已安装 Git LFS 的受影响检出中，检查它的端点和最后一次失败：

git -C project lfs env
git -C project lfs logs last

在本地查看输出；仓库 URL 和日志可能暴露身份或认证信息。先定位第一个失败的阶段：

  1. 连接 LFS API。
  2. 取得 Batch API 的下载动作。
  3. 访问该动作给出的下载 URL，它可能使用不同的对象存储主机和随附的请求头。
  4. 传输对象正文。

既要检查仓库的 LFS 端点覆盖，也要检查实际 URL。LFS 有自己的 HTTP 实现、配置和继承来的代理环境。对 Git LFS 3.7.0，要按它的代理选择顺序处理实际请求 URL。能连通普通的 Git HTTPS 主机，并不等于走通了之后每一条对象路由。对象存储主机的认证失败也与代理 407不同。

如果你确实要下载，在受控仓库里单独执行一次 fetch 就能复现失败，不必再克隆一次：

git -C project lfs fetch

这会传输对象，不是只读的设置查询。之后确认所需内容确实存在。部分检出里残留的小指针不是大文件，之前某条 Git 命令成功也不能证明 LFS 传输已经完成。

相关文章