技術 · 實用指南
Git 顯示 fatal: bad object？刪除前先證明參照、物件與儲存庫邊界
先保全本機工作，再解析精確參照、測試物件、區分淺層歷史或部分複製，最後只修證據確認損壞的層。
`fatal: bad object` 不是單一故障。Git 可能解析到遺失物件、遇到無效參照、跨過淺層或部分複製邊界、開啟錯誤儲存庫，也可能真的發現物件損壞。
修改前先保全工作樹與儲存庫中繼資料，再證明精確參照、物件 ID、物件類型與可達性邊界。安全修復只改變證據確認的最小層，並保留可驗證的復原路徑。
修復前先替工作建立快照
在 checkout、reset、gc、prune、repack 或刪除參照前，複製工作樹與儲存庫中繼資料。記錄狀態、根目錄、Git 目錄、遠端、工作樹與全部參照；移除憑證但保留參照名稱和物件 ID。
大型儲存庫至少保留未提交檔案、HEAD、鬆散與打包參照、reflog、shallow 檔案、alternates 與部分複製設定。可測試全新複製，但核對本機提交前不要取代損壞副本。
解析精確名稱並測試精確物件
把錯誤中 bad object 後的內容當作證據。若是參照，用 show-ref、for-each-ref 與 rev-parse 驗證；解析出物件 ID 後，用 cat-file -e 與 cat-file -t 測試存在性和類型。
也要證明失敗程序使用的儲存庫與工作樹。編輯器、掛鉤、服務和 CI 可能帶著不同目錄或 GIT_DIR 執行；若目前 shell 能開啟物件，應重現原環境。
解讀 fsck，不把每一行都當資料遺失
在保留副本上執行 git fsck --full。遺失物件、無效參照指標、雜湊不符或損壞物件需要處理；dangling 只表示物件存在但未被一般參照觸及，可能是復原線索。
把第一條有效錯誤映射回精確參照或父邊。若只有一個可捨棄的本機參照指向遺失物件，可考慮定向 update-ref -d；絕不能擴大成批次刪除。
區分刻意的歷史邊界與遺失資料
檢查 .git/shallow、CI 深度、部分複製過濾器、promisor 遠端、alternates 與子模組。淺根是刻意邊界；actions/checkout 預設只取得一個提交，舊祖先缺席不代表目前提交損壞。
確認遠端與預期歷史後，才深化或取得精確參照。fetch-depth: 0 要求完整分支與標籤歷史，但較小的定向取得可能已足夠；取得失敗仍須保留壞參照與物件復原兩條分支。
選擇最小修復並證明收尾
陳舊符號或遠端參照應指向已驗證分支，或只刪除已證明可捨棄的那一個參照；淺層複製應深化；真正遺失的可達物件應從可靠複製、備份或物件庫復原。
重試原命令，再檢查精確參照、物件與 fsck 解讀。確認未提交和僅本機工作仍在；保留損壞副本，直到全新複製或備份獨立證明復原路徑。
