技術 · 實用指南

Git LFS 複製後只剩指標文字？改寫歷史前先證明物件交付

保留指標，逐層核對屬性、端點、物件擷取與 checkout，再驗證精確 SHA-256 和大小。

作者 Watch at Ease News · 2 分鐘閱讀發布於 2026年10月16日下午2:37 UTC

工作樹裡的 Git LFS 指標不等於檔案損壞。它記錄規範版本、SHA-256 物件 ID 與位元組大小；故障可能位於屬性、smudge 政策、端點、驗證、遠端物件或 checkout。

先保留 clone 與指標，再證明從提交指標到精確物件位元組的整條鏈，避免把可復原的缺物件事故變成歷史改寫。

保留指標並分類

複製可疑檔案，記錄路徑與 commit，只讀檢查 version、oid sha256 與 size。

若不是有效指標就停止；若有效，不要手動替換、廣泛 reset 或啟動 migrate。

用 git check-attr 與 git lfs ls-files 核對路徑、OID 與 .gitattributes。

記錄 git lfs env、版本、ref 與 filter；正確提交仍可能因 filter 被跳過而留下文字。

檢查 GIT_LFS_SKIP_SMUDGE、fetchexclude 與 CI 設定；跳過 smudge 不等於物件遺失。

針對精確 remote/ref fetch 並保存狀態，再 checkout 選定路徑，分開下載與物化證據。

記錄 LFS 端點與驗證；Git 走 SSH 時，LFS 仍可能走 HTTPS。

區分 401、403、404、逾時與排除。精確 OID 的 404 不能靠重裝或 reset 修復。

確認本地 object store 已有 OID，再只 checkout 受影響路徑，不先用 fetch --all。

核對 SHA-256、大小與 git status，直到每個邊界都有證據。