Codex 改錯後，怎樣用 Git 只恢復一個檔案

一個檔案改壞了，其他檔案裏還有自己沒提交的工作，怎樣只撤回目標檔案？先檢查 Git 基線和修改範圍，再決定是否恢復整個檔案。

下面的指令會覆蓋目標檔案的工作區內容。只在確認該檔案裏的未提交改動都準備放棄、而 HEAD 確實是正確版本時使用。

先看差異與暫存區

在倉庫目錄執行：

複製git status --short
git diff HEAD -- check_products.py
git diff --cached --name-only

第三條幫助確認有沒有已經暫存的內容。原演示沒有暫存改動，check_products.py 裏只有準備撤回的模擬誤改，最後一次提交是正確基線。

如果同一檔案裏還混着要保留的修改，先逐塊核對並留存它們，不要直接套下面的恢復整個檔案的指令。

只恢復指定檔案的工作區

複製git restore --source=HEAD --worktree -- check_products.py

--source=HEAD 明確恢復來源，--worktree 指向工作區，-- 後面只列目標檔案。它不會替你判斷程式碼好壞，也不會把已經提交的誤改自動找回到正確版本。Git restore 官方說明

隨後再看 git status --short、目標檔案差異，並執行相關測試。其他檔案還在不代表內容一定沒變，重要保留項也要核對。

原演示驗證了哪些結果

2026年10月14日，在 Windows 的隔離 Git 倉庫裏，人為把「數值必須大於0」改為「允許0」，模擬錯誤。測試出現2處失敗；另一個檔案有未提交補充，還有一個未跟蹤草稿。

恢復目標檔案後，內容與基線一致，6項測試通過。其他補充與草稿保留，內容校驗一致。這是教學模擬，不是 Codex 真實失敗記錄。

交給 Codex 時，可以先讓它唯讀檢查：

複製列出目標檔案準備撤回的內容、恢復來源和必須保留的修改。
先不要執行恢復；確認範圍後再處理。
完成後執行相關檢查，報告保留項是否改變。

沒有正確 Git 基線、目標檔案混有有價值的修改，或錯誤已提交時，需要另行選擇恢復辦法。原稿於2026年10月27日整理，未重新執行恢復實驗。

香港繁體版整理日期：2026年10月28日。原文引用的產品說明核對截至2026年10月27日；原實驗日期與範圍保留於文中。

查看 AI Coding 系列全部文章