遇到单个LFS文件只推送了占位符、克隆时报Smudge error的情况，大概率是这个文件的LFS对象没有成功同步到二次远程仓库，咱们一步步排查解决：

1. 确认本地LFS对象状态 #

首先得确保本地有完整的LFS文件对象：

• 检查文件是否被LFS正确跟踪：

  git lfs ls-files | grep "<涉事文件名>"
  

  输出应该显示该文件对应的OID（一串哈希值），确认这个OID和原仓库的一致。
• 验证本地是否存在该LFS对象：

  git lfs objects verify --all | grep "<OID>"
  

  如果显示对象缺失，先从原仓库拉取完整对象：

  git lfs pull origin "<涉事文件路径>"
  

  （把origin换成你的原远程仓库名）

2. 手动推送涉事LFS对象到二次远程 #

如果本地对象没问题，那大概率是推送时这个对象没传到二次远程，手动推送特定OID是最直接的办法：

• 用第一步拿到的OID，执行推送命令：

  git lfs push <二次远程仓库名> <OID>
  

  比如你的二次远程叫secondary，OID是abcdef123456，就输git lfs push secondary abcdef123456
• 推送完成后，再同步整个仓库的LFS对象：

  git lfs push <二次远程仓库名> --all
  

  最后再推送Git仓库的提交记录：

  git push <二次远程仓库名> --all
  

3. 检查二次远程的LFS配置 #

有时候是远程仓库的LFS支持没开或者配置有误：

• 确认你的二次远程仓库已经启用了LFS功能（比如GitHub/GitLab需要在仓库设置里打开LFS开关）
• 检查本地针对二次远程的LFS URL配置是否正确：

  git config --get remote.<二次远程仓库名>.lfsurl
  

  如果没有输出，手动添加配置：

  git config remote.<二次远程仓库名>.lfsurl https://<二次远程仓库地址>/info/lfs
  

4. 清理缓存后重新推送（可选） #

如果以上步骤没用，可能是本地LFS缓存有问题：

• 清理本地无用的LFS对象：

  git lfs prune
  

• 重置LFS状态并重新拉取原仓库的对象：

  git lfs reset
  git lfs pull origin
  

  之后再重复步骤2的推送操作。

验证解决效果 #

完成后可以做两个验证：

1. 登录二次远程仓库的托管平台，查看涉事文件，确认它显示为LFS文件（通常会有"LFS"标识，且内容不是占位符文本）
2. 克隆二次远程仓库测试：

   git lfs clone <二次远程仓库地址>
   

   或者普通克隆后执行git lfs pull，确认不再出现Smudge error。

内容的提问来源于stack exchange，提问作者alecbz