技术 · 实用指南
Git LFS 克隆后只剩指针文本？改写历史前先证明对象交付
保留指针，逐层核对属性、端点、对象抓取与 checkout，再验证精确 SHA-256 和大小。
工作树里的 Git LFS 指针不等于文件损坏。它记录规范版本、SHA-256 对象 ID 和字节大小；故障可能位于属性、smudge 策略、端点、认证、远端对象或 checkout。
先保留克隆与指针，再证明从提交指针到精确对象字节的整条链。这样能避免把可恢复的缺对象事故变成历史改写，也能发现 CI 实际分析了指针文本。
保留指针并分类
复制可疑文件，记录路径和提交，只读检查 version、oid sha256 与 size，把三项作为待恢复对象身份。
若不是有效指针就停止本流程；若有效，不要手工替换、广泛 reset 或启动 migrate。
证明本 ref 的跟踪与过滤范围
用 git check-attr -a -- path 和 git lfs ls-files -l 核对路径、OID 与 .gitattributes；其他分支或父目录规则不能证明当前 checkout。
记录 git lfs env、版本、ref 和 filter 配置。提交可正确，而工作树因 filter 缺失、跳过或范围不符保留文本。
分开 smudge、fetch 与 checkout
检查 GIT_LFS_SKIP_SMUDGE、lfs.fetchexclude 和 CI 设置。跳过 smudge 是 checkout 策略，不等于对象丢失。
针对精确 remote/ref 执行 git lfs fetch origin main 并保存状态，再对选定路径 checkout；不要把下载与物化合并成一个结论。
证明端点、认证与远端可用性
用 git lfs env 记录端点与认证。Git 可走 SSH，而 LFS 仍走 HTTPS；克隆成功不证明 LFS 凭据成功。
区分 401、403、404、超时与排除规则。若精确 OID 返回 404，重装或 reset 无法生成服务器不存在的字节。
窄范围物化并验证字节
成功 fetch 后确认本地 LFS object store 中存在 OID，再只 checkout 受影响路径；不要首先用 fetch --all 扩大范围。
核对恢复文件 SHA-256、大小和 git status --porcelain。只有对象、端点、ref 与工作树状态全部解释清楚才结束。
