---

實戰教程：從"對象文件為空"到倉庫重生——修復 Git 倉庫損壞全記錄

當你投入于項目中，執行一個再普通不過的 git add . 命令時，卻被一連串鮮紅的 fatal: loose object ... is corrupt 錯誤迎面痛擊，這足以讓任何開發者心頭一緊。這標志著你的本地 Git 倉庫的心臟——對象數據庫——已經受損。

幸運的是，這通常是可修復的。本文將通過一個真實的修復案例，一步步帶你走過診斷、清理、修復和恢復的全過程，讓你在面對這類問題時不再束手無策。

案發現場：一個嚴重損壞的倉庫

故事始于一個開發者，我們稱他為 Alex。Alex 在他的項目 ultra-codetrack 中準備提交代碼時，遇到了問題。

1. 初步診斷：錯誤頻發

Alex 首先嘗試暫存文件，但立刻收到了錯誤：

user@ubuntu:~/projects/ultra-codetrack$ git add .
error: 對象文件 .git/objects/37/a2045bc05ca87e84259787c4b118ea3e638c67 為空
fatal: 松散對象 37a2045bc05ca87e84259787c4b118ea3e638c67（保存在 .git/objects/37/a2045bc05ca87e84259787c4b118ea3e638c67）已損壞

為了評估損壞范圍，Alex 運行了 Git 的文件系統檢查工具 git fsck。結果令人擔憂，大量的對象文件都報告為空或丟失：

user@ubuntu:~/projects/ultra-codetrack$ git fsck
error: 對象文件 .git/objects/0a/86f6... 為空
error: 0a86f667...：對象損壞或丟失
error: 對象文件 .git/objects/1b/f11a... 為空
error: 1bf11a22...：對象損壞或丟失
error: 對象文件 .git/objects/37/a204... 為空
error: 37a2045b...：對象損壞或丟失
# ... 此處省略大量類似的錯誤報告 ...

這表明倉庫的損壞是系統性的，多個對象文件已變為空文件。

2. 失敗的嘗試

Alex 嘗試了一個常見的修復手段——回退到上一個提交，但由于相關的對象也已損壞，這個操作同樣以失敗告終：

user@ubuntu:~/projects/ultra-codetrack$ git reset --hard HEAD~1
error: 對象文件 .git/objects/1b/f11a... 為空
fatal: 松散對象 1bf11a22...（保存在 ...）已損壞

3. 關鍵信息：確認遠程倉庫存在

在進行破壞性修復之前，最重要的一步是確認存在一個健康的遠程備份。Alex 使用 git remote -v 檢查了他的遠程倉庫配置：

user@ubuntu:~/projects/ultra-codetrack$ git remote -v
origin  git@example.com:my-group/ultra-codetrack.git (fetch)
origin  git@example.com:my-group/ultra-codetrack.git (push)
upstream        https://example.com/orig-repo/ultra-codetrack.git (fetch)
upstream        https://example.com/orig-repo/ultra-codetrack.git (push)

太好了！存在一個名為 origin 的遠程倉庫。這意味著 Alex 可以從遠端拉取丟失的對象來修復本地倉庫。修復工作可以正式開始了。

修復之旅：四步讓倉庫重獲新生

準備工作：創建安全備份

在動手之前，務必備份 .git 目錄，以防萬一。

cp -R .git .git_backup

第 1 步：清理戰場——刪除所有空對象

既然已經知道問題源于大量空文件，第一步就是將它們全部清理掉。使用 find 命令可以一勞永逸地解決這個問題。

user@ubuntu:~/projects/test$ find .git/objects/ -size 0 -exec rm -f {} \;

這個命令會找到 .git/objects 目錄下所有大小為 0 的文件并強制刪除它們。執行后，最初的“對象文件為空”錯誤源頭被清除了。

第 2 步：再次診斷——發現新的問題

清除了空文件后，Alex 再次運行 git fsck --full 進行全面體檢。這次的報告和之前不同了：

user@ubuntu:~/projects/ultra-codetrack$ git fsck --full
正在檢查對象目錄: 100% (256/256), 完成.
正在檢查對象: 100% (7302/7302), 完成.
error: refs/heads/dev：無效的 sha1 指針 1bf11a22ae9f938028a3e63812fc50e53710b4d6
error: refs/remotes/origin/dev：無效的 sha1 指針 1bf11a22ae9f938028a3e63812fc50e53710b4d6
error: HEAD：無效的 sha1 指針 1bf11a22ae9f938028a3e63812fc50e53710b4d6
缺失 blob 37a2045bc05ca87e84259787c4b118ea3e638c67
懸空 blob ... (大量懸空對象)

日志分析：

• 之前的“對象為空”錯誤消失了。
• 出現了新的致命錯誤：無效的 sha1 指針。這意味著 HEAD（當前指向）、本地 dev 分支、甚至遠程跟蹤分支 origin/dev 都指向了一個我們剛剛刪除的、損壞的提交對象 (1bf11a...)。
• 同時報告了一個 缺失 blob，這也是被我們刪除的對象之一。
• 大量的“懸空 (dangling)”對象是正常的，它們是本地存在但沒有任何引用指向的對象，通常無害。

現在的核心矛盾是：分支引用已損壞，指向了不存在的位置。

第 3 步：遠程救援——從 Origin 獲取健康對象

這是最關鍵的一步。Alex 使用 git fetch 嘗試從 origin 遠程倉庫下載所有本地缺失的對象和最新的分支信息。

user@ubuntu:~/projects/test$ git fetch origin
error: refs/heads/dev 沒有指向一個有效的對象！
error: refs/remotes/origin/dev 沒有指向一個有效的對象！
remote: Enumerating objects: 44, done.
remote: Counting objects: 100% (44/44), done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 26 (delta 19), reused 0 (delta 0), pack-reused 0 (from 0)
展開對象中: 100% (26/26), 完成.
來自 example.com:my-group/test* [新分支]          dev        -> origin/dev

日志分析：

• 命令開頭依然報錯，因為它檢查了本地損壞的分支引用。
• 但關鍵在于最后一行：* [新分支] dev -> origin/dev。Git 成功地從遠程獲取了 dev 分支的健康狀態，并創建了一個全新的、健康的遠程跟蹤分支 origin/dev。所有缺失的對象（包括之前報告的 缺失 blob）現在都已下載到本地。

第 4 步：終極恢復——重置本地分支

雖然健康的對象已經下載完畢，但 Alex 的本地 dev 分支和 HEAD 仍然是壞的。我們需要手動將它們“嫁接”到剛剛下載的健康分支上。

使用 git reset --hard 可以完成這個任務，這次的目標是健康的 origin/dev。

# 首先確保你就在損壞的 dev 分支上 (git checkout dev)
git reset --hard origin/dev

這條命令會做三件事：

1. 將當前分支（dev）的指針強制移動到與 origin/dev 相同的位置。
2. 更新 HEAD 指針，解決 HEAD：無效的 sha1 指針 錯誤。
3. 將工作目錄和暫存區的內容重置為該提交的狀態，確保所有文件都恢復正常。

最后一步：驗證成果

完成重置后，再次運行健康檢查：

git fsck --full

此時，所有 error: 開頭的錯誤都應該消失了。你的倉庫已經恢復如新！git status 和其他命令也應該可以正常工作了。

結論

通過這個真實的案例，我們可以總結出修復 Git 本地倉庫損壞的黃金法則：

1. 備份為先：永遠在修復前備份 .git 目錄。
2. 清理現場：使用 find .git/objects/ -size 0 -exec rm -f {} \; 刪除所有空的損壞對象。
3. 診斷問題：運行 git fsck --full 確定損壞范圍，通常會從“對象為空”轉變為“無效指針”或“缺失對象”。
4. 遠程拉取：執行 git fetch 從遠程倉庫下載健康的對象和分支信息。
5. 強制重置：使用 git reset --hard origin/<branch_name> 將本地損壞的分支重置到健康的遠程跟蹤分支上。

這個過程證明了，即使面對看起來非常棘手的 Git 倉庫損壞，只要你有一個遠程備份并遵循正確的步驟，就總能化險為夷。