科技 · 實用指南

Git LFS 說檔案本應是指標？在不遺失工作副本下修復索引

先保存檔案，證明屬性規則與 Git 物件的錯配，再選擇窄範圍正規化或協同歷史遷移，最後用全新複製驗收。

作者 Watch at Ease News · 3 分鐘閱讀發布於 2026年10月19日凌晨12:42 UTC

此警告通常表示 .gitattributes 要求路徑交給 Git LFS，但提交或索引仍把完整檔案存成一般 Git blob。clean 過濾器會產生指標比較，所以 reset 後仍可能顯示修改。

不要先執行 git reset --hard、刪除 .git/lfs 或強制推送。先保留工作區位元組，核對規則與物件，只修必要範圍，再證明遠端 LFS 物件可用。

1. 先保存位元組再改 Git

在 reset、checkout 或遷移前，把受影響檔案複製到儲存庫外或記錄加密雜湊，並保存 git status、路徑與目前分支。

若工作樹還有無關修改就停止。最好在乾淨分支或一次性複製中正規化，保存檔則留在儲存庫外。

使用 git check-attr -a -- path 找到實際生效規則，包括巢狀 .gitattributes 與區分大小寫的樣式，再檢查索引或 HEAD 物件而不覆蓋工作檔。

真正 LFS 指標是含版本、物件 ID 與大小的短文字。若路徑受 LFS 追蹤但 HEAD 是完整 blob，警告代表表示層錯配。

目前分支修復時，明確寫好規則，在乾淨樹對該路徑執行 git add --renormalize -- path 並檢查暫存差異。暫存內容應成為指標。

只提交審過的規則與指標修正。它從此提交起修正此分支；其他受影響分支要明確逐一處理。

只有舊提交必須轉換或託管限制仍看到歷史大檔時才用 git lfs migrate。在一次性複製測試 --no-rewrite 或 import --fixup 並列出精確引用。

歷史遷移會改變提交 ID，可能需要協同強推與重新複製。先備份引用、安排切換，不要在共享遠端探索範圍。

對選定範圍跑 git lfs fsck --pointers，再用 git lfs fsck 檢查本機物件。推送前核對 git lfs ls-files 與指標 OID。

除了 Git 引用也要確認 LFS 物件上傳。Git push 成功或狀態乾淨不能證明大物件已到遠端。保留原件與還原檔雜湊。

在空目錄安裝 Git LFS 後全新複製，檢出修正引用，確認沒有警告或假修改，並比對還原檔與保存原件的雜湊和大小。

屬性、提交指標、遠端物件與全新工作檔一致才驗收；另一位協作者或 CI 通過前保留備份。