Git 遺失檔案?還原已刪除及未提交的檔案

還原已刪除及未提交的 Git 遺失檔案

執行分支切換後,來源資料夾看起來空空如也。硬重置會刪除今早的編輯內容。又或者,執行清理指令時,會刪除你從未提交的腳本。這些 Git 遺失的檔案 雖然情況看似相似,但正確的恢復方法取決於 Git 是否曾儲存過遺失的內容。.

工作資料夾中找不到檔案,並不一定代表該檔案已從儲存庫中消失。提交、暫存區、其他分支或暫存區中,可能仍包含可用的副本。在掃描磁碟之前,請先從這些位置開始檢查。.

本指南將依照此順序說明。若 Git 中沒有該檔案的副本,且原始檔案已從儲存空間中消失,則 已刪除檔案復原指南 涵蓋了下一個分支。針對該特定的 Windows 情境,, Magic Data Recovery 提供儲存層級的復原選項;它不會重建 Git 歷史紀錄。.

目錄

Git 遺失檔案:選擇正確的恢復方法

最簡短的答案: 從索引或已知的提交中還原受追蹤的檔案。檢查 reflog 以尋找遺失的提交,並檢查本地歷史紀錄以尋找 Git 從未儲存過的編輯內容。僅在沒有任何可用副本時,才使用磁碟還原功能。.

發生了什麼事?

可能存在副本之處

從這裡開始

您刪除了受追蹤的檔案,但未將其移至暫存區

Git 的索引

還原個別路徑

你是刻意刪除的,還是使用了 git rm

最後一次提交

從該處還原該路徑 HEAD

您已執行刪除操作

較早的提交

尋找包含該檔案的修訂版本

重置、重新基準或修正會隱藏某個提交

本地重播日誌

在舊的提交處建立一個還原分支

你已編排內容,但從未提交

索引或存留的 blob 物件

先檢查索引,然後檢查物件

您從未對該內容進行過新增、提交或暫存

編輯歷史、備份、原始磁碟

在執行磁碟復原前請先檢查副本

切換分支後,檔案消失了

另一個分支或檢出設定

請先確認地點及分行

這項區別之所以重要,是因為 Git 還原未提交的檔案 搜尋結果:「未提交」包含已暫存的內容以及 Git 從未儲存過的變更。這兩種情況的還原限制各不相同。.

在執行指令之前,請先保護儲存庫

暫停建置、依賴項安裝及自動清理。若磁碟運作正常,請將儲存庫(包含隱藏的 Git 元資料)複製到另一顆實體磁碟上。一般的克隆操作並不會保留所有本機復原線索,例如您的索引、引用日誌(reflog)以及無法存取的物件。.

對於關聯的工作樹或子模組,, .git 該檔案可能是指標檔案,而非目錄。請一併保留它所指向的 Git 目錄。若您懷疑是實體硬碟故障,請停止一般的複製與掃描作業,並尋求專業的資料復原協助。.

在執行指令之前,請先保護儲存庫

在復原過程中請避免使用以下指令:

  • git reset --hard, ,此操作會捨棄已追蹤的工作變更,並可移除阻礙的未追蹤路徑。.
  • git clean -fd 或 git clean -fdx, ,該功能會移除未被追蹤的內容;; -x 也包含被忽略的檔案。.
  • git gc --prune=now 和 git prune, ,這可能會刪除您仍需要的物件。.

Git 的 重設文件 和 簡潔的文件 解釋這些影響。當您僅需一個遺失的檔案時,通常無需執行整個儲存庫的回滾。.

請參考以下來自儲存庫根目錄的範例。請將範例中的檔案名稱和雜湊值替換為您自己的。這些還原指令需要 Git 2.23 或更新版本,並可在 Windows 上的 Git Bash,以及 macOS 和 Linux 終端機中執行。.

確認檔案是遺失了,還是只是存放在其他地方

嘗試之前 Git 檔案復原, 請確認您開啟的是哪個儲存庫和分支:

  1. git rev-parse –show-toplevel
  2. git status --short
  3. git branch --show-current
  4. git branch --all

接著,請在「資源管理員」或「Finder」中,以確切的檔案名稱、副檔名及大致的修改時間進行搜尋。請檢查另一個檢出副本、已重新命名的專案資料夾、外部儲存裝置,以及您所使用編輯器的排除資料夾。.

三個 Git 概念便能解釋絕大部分 Git 遺失的檔案 案例:

  • 工作樹: 您目前正在編輯的檔案。.
  • 目錄: 您使用 選取的內容 git add 用於下一次提交。.
  • 提交: Git 歷史紀錄中已儲存的專案快照。.

Git 不會自動儲存每一次編輯。暫存會擷取當下的內容,因此後續的編輯可能僅存在於您的工作樹中。請參閱 Git 的 變更記錄指南.

在 Git 中提交前還原已刪除的檔案

最適合 一個您已在本地刪除,但儲存庫中仍保留其內容的受追蹤檔案。.

首先,檢查路徑:

  1. git status --short -- src/app.js
  2. git diff -- src/app.js
  3. git diff --cached -- src/app.js

簡而言之,第一欄描述索引的變更;第二欄則描述工作樹的變更。. D 意指未分階段的刪除。. D 意指分階段刪除。.

從索引中還原未進入暫存區的刪除操作

至 在 Git 中還原已刪除的檔案 當索引中仍包含該檔案時:

  1. git restore -- src/app.js

此操作會還原已暫存的內容,這些內容可能與最後一次提交有所不同。例如,若您在刪除檔案之前已將更新後的函式暫存,Git 便能恢復該暫存內容。此外,此指令無法恢復後續未暫存的編輯內容。.

從 HEAD 還原已標記待刪除的變更

若您已執行刪除操作,該索引便不再保留該路徑下的檔案。在保留任何有用的副本後,請還原其最後提交的版本:

  1. git restore --source=HEAD --staged --worktree -- src/app.js

這會同時變更該路徑的索引和工作檔。它並不會還原至較新且尚未提交的版本。Git 的 還原文件 說明來源與目的地選項。.

對於存放於尚未有提交記錄的儲存庫中、新新增的檔案,, HEAD 該檔案目前尚不存在。如果索引中仍包含該檔案,請改用基於索引的方法。.

從較早的提交或另一個分支還原檔案

最適合 已提交的刪除、較舊的檔案版本,或是僅在您當前分支中缺失的檔案。.

先從它的歷史說起:

  1. git log --all --oneline -- src/app.js

若您無法記起其舊路徑,請列出刪除記錄:

  1. git log --all --diff-filter=D --summary

在還原任何內容之前,請先檢查候選提交:

  1. git show abc1234:src/app.js

更換 abc1234 使用一個實際包含該檔案的提交。然後僅還原該路徑:

  1. git restore --source=abc1234 -- src/app.js

如果 abc1234 這是刪除提交,請使用以下指令檢查其父提交: git show abc1234^:src/app.js. 若是簡單的刪除操作,父提交可能已包含所需的版本。合併提交通常有多個父提交,因此請務必驗證內容,而非直接假設第一個父提交是正確的。.

適用於 切換分支後 Git 出現檔案遺失的情況, 檢視包含該檔案的分支:

  1. git show feature/login:src/app.js
  2. git restore --source=feature/login -- src/app.js

這些範例會保留您當前的分支和其他檔案。請檢查 Git 日誌文件 用於歷史搜尋以及 Git 顯示文件 用於檢查儲存的內容。若有人重新命名了檔案,歷史紀錄搜尋可能需要舊的檔案名稱。.

在執行「reset」後,若 Git 中的變更遺失,請使用 Reflog

最適合 在執行重置、重新基線、修正或分支移動後,從可見歷史中消失的已提交工作。.

適用於 Git 硬重置的恢復方法, 請檢視您的本地參考歷史紀錄:

  1. git reflog –date=local

找出發生該不必要操作之前的提交。確認其內容後,將其保留在一個新的分支名稱下:

  1. git show –stat abc1234
  2. git branch recovery-lost-work abc1234

建立分支並不會切換您的工作樹。您事後可以從該分支檢視或還原個別檔案。.

Reflog 並不會記錄每一次檔案編輯。. 它會記錄參考的移動紀錄。如果遺失的內容從未被提交,僅靠 reflog 無法恢復該內容。條目和物件的保留時間也有限。Git 在其 reflog 文件.

適用於 Git 遺失的檔案 刪除分支後,該 Git 官方資料恢復指南 說明如何挽救尚存的提交。一旦確認某個提交仍有價值,請立即將其保留下來。.

檢查儲存庫中的內容以及已標記為「待提交」但尚未提交的內容

從「藏匿處」還原檔案

在擔任 Git 遺失的變更 若要永久保留,請確認您是否已將它們收好:

  1. git stash list
  2. git stash show –include-untracked –name-only ‘stash@{0}’
  3. git stash show -p –include-untracked ‘stash@{0}’

選擇快照時應依據其內容,而不僅僅是日期。在具有受保護副本且工作樹乾淨的情況下,請套用正確的條目:

  1. git stash apply ‘stash@{0}’

不像 pop, 申請 將該項目保留在暫存清單中。此操作可能會導致衝突,因此請在繼續之前先檢視結果。.

預設的儲存庫不包含未追蹤的檔案。這些檔案需要 -u 在建立暫存區時,被忽略的檔案需要 -a. 請參閱 Git stash 文件.

從倖存物件中復原暫存內容

適用於 Git 還原未提交的檔案 您先前曾執行過的案例 git add, 檢查索引是否仍包含該內容:

  1. git ls-files –stage — src/app.js
  2. git show :src/app.js

第二條指令會顯示帶有索引的版本。該 Git ls-files 文件說明 說明如何檢查索引條目。.

如果重置操作已替換索引,則可能仍會殘留一個包含已暫存內容的 BLOB。請在您保留的儲存庫副本上進行操作:

  1. git fsck –full –no-reflogs –unreachable

關於一個 無法存取的資料塊 候選人,檢視其內容:

  1. git cat-file -p BLOB_HASH

更換 BLOB_HASH 並附上實際的物件 ID。請尋找具有辨識度的函式、註解或設定值。Blob 僅包含內容,而非原始檔案名稱,因此辨識過程可能需要一些時間。.

對於懸掛的物體,, git fsck --lost-found 撰寫恢復相關資料,並發佈於 .git/lost-found/. 它並未承諾會匯出所有無法存取的物件,也不會重建完整的目錄樹。請參閱 Git fsck 和 Git cat-file.

使用 Git Bash 的輸出重定向功能,或採用能保留位元的匯出方法,將已確認的 blob 匯出至另一個磁碟機上的新檔案。請避免直接從終端機輸出中複製二進位內容。此方法有助於 Git 暫存檔案的恢復, ,但僅限於相關物件保持完整時。.

透過編輯器歷史紀錄和備份還原未被追蹤的檔案

最適合 已被刪除的檔案,或是 Git 從未新增、提交或暫存的較新編輯內容。.

至 還原未追蹤的檔案, 在掃描儲存空間之前,請先檢查您的編輯器。在 VS Code 中,開啟「指令調色盤」並執行:

  1. 地方史:尋找待修復的條目

選取遺失的檔案,檢視可用的項目,並比較其內容。對於現有檔案,「時間軸」檢視亦可顯示本機歷史紀錄。此功能的可用性取決於已儲存的項目、設定及保留政策;它並非未儲存輸入內容的保證記錄。微軟在 VS Code 使用者介面指南.

接著,請檢查「資源回收筒」或「垃圾桶」、雲端已刪除項目、雲端版本歷史紀錄以及系統備份。透過終端機執行的刪除指令可能會繞過「資源回收筒」。請檢查原始儲存路徑,而非假設專案中的每個檔案都存放在儲存庫內。.

遠端儲存庫可以還原已推送的提交,但不會自動包含本機未追蹤的檔案、未儲存的編輯內容或私有暫存區。如果遺失的工作內容曾於其他地方分享過,請向團隊成員詢問是否有其他副本。.

適用於 git clean recovery, 這些外部副本特別重要:Git 無法僅因刪除操作發生在儲存庫內部,就恢復它從未儲存過的內容。.

當 Git 遺失檔案時,需要進行磁碟復原

請在回答以下問題後,才進行儲存空間復原:

  1. 正確的分支、索引、提交、暫存區或存留物件中,是否包含所需的版本?
  2. 您的編輯器、雲端歷史紀錄或備份功能能否提供這項功能?
  3. 該檔案是否已從其原始儲存位置中遺失?
  4. 該裝置是否仍能保持穩定且可被偵測到?

如果沒有可用的副本,且該檔案確實已消失,, Git 遺失的檔案 便會演變成磁碟層級的問題。例如:被清理程式移除的未追蹤腳本、已刪除的專案目錄,或是包含本地工作檔案的已格式化磁碟。.

使用 Magic Data Recovery 還原已刪除的專案檔案

Magic Data Recovery 支援涉及刪除、格式化及檔案系統錯誤等 Windows 資料恢復情境。其掃描與篩選工作流程提供了一種實用的方法,可在 Git 未儲存副本時檢查可恢復的專案檔案。.

支援 Windows 7/8/10/11 和 Windows Server

其相關優勢在於搜尋範圍:Git 僅搜尋自身的記錄,而此工具則會掃描原始儲存空間。對於已刪除的本地腳本或專案存檔,這使得它比反覆執行 Git 指令更適合作為下一步動作。此外,視覺化的掃描與檢視工作流程,也讓您能在將檔案還原至專案之前,先預覽並確認候選檔案。.

使用 Magic Data Recovery 還原已刪除的 Git 專案檔案

請按照以下四個步驟操作:

  1. 請安全地進行設定。. 若情況允許,請從另一顆磁碟或另一台電腦安裝並執行此工具。請盡量減少對受影響裝置的寫入操作。.
  2. 掃描原始卷冊。. 請選擇原本存放遺失檔案的磁碟機,即使您目前的檢出位置位於其他地方。.
  3. 審查候選人。. 使用可用的檔案名稱、路徑及類型篩選器。預覽受支援的格式;匯出後在編輯器中驗證來源檔案。.
  4. 請到別處恢復。. 將選定的檔案儲存至另一個實體磁碟,並在驗證完成前保持原始儲存庫不變。.

還原操作可能會還原舊版本、不完整的檔案,或名稱已變更的檔案。此工具無法補全未儲存的程式碼、重建遺失的提交關聯,亦無法自動還原依賴關係。其適用性在於,當原生還原選項失敗時,能處理實際發生的儲存資料遺失問題。.

在重新加入專案之前,請先驗證已恢復的檔案

適用於 Git 遺失檔案的還原, 所謂的成功,是指能實際使用的內容,而不僅僅是掃描結果中的檔案名稱。.

將還原的原始碼檔案在另一個資料夾中開啟。檢查重要函式、編碼、行尾格式,以及最新變更是否確實存在。檔案大小和時間戳記雖能提供線索,但並不能證明您找到的是正確版本。.

將候選方案與現行專案進行比較。僅將已驗證的檔案複製到受保護的工作副本中,並進行審查 git diff, ,並執行相關的建置或測試。請分別確認設定檔與外部資源。.

最後,請在復原分支上提交已還原的變更。請避免替換整個 .git 包含部分已恢復元資料的目錄;若儲存庫的完整性仍無法確定,請另行恢復原始內容。.

若復原失敗,請檢查限制條件

更深入的掃描無法還原已被覆寫的內容。SSD TRIM 以及隨後的裝置清理作業,同樣會使已刪除的資料無法被讀取。微軟的 Windows 檔案恢復指南 建議減少使用該磁碟,並將恢復的資料儲存至另一顆磁碟。.

若裝置反覆斷線、發出異常聲響或出現讀取錯誤,請停止重複掃描。若裝置運作穩定,請在嘗試其他軟體之前,先重新檢查原始磁區及任何外部備份。.

部分 Git 遺漏檔案 需要另一種解釋。稀疏檢出(Sparse checkout)會刻意將某些受追蹤的路徑排除在工作樹之外,而子模組(submodules)則會維持獨立的儲存庫內容。在將空資料夾視為刪除之前,請先檢查這些設定。Git 文件 稀疏檢出 和 子模組初始化.

避免未來工作中發生 Git 檔案遺失的情況

將有用的里程碑提交,並將重要的分支推送到遠端儲存庫。在清理工作區之前,請使用 git clean -nd; 若您打算將被忽略的檔案納入其中,請檢查 git clean -ndx 也是。.

請保持編輯器的本地歷史記錄功能啟用,並備份整個專案資料夾。備份內容應包含未被追蹤的資源,以及 Git 遠端無法取代的外部資產。檢視 .gitignore 請注意:若刻意忽略某個重要檔案,系統將不會為其建立備份。.

在執行重置或重新基準化之前,請先保存正在進行的工作,並確認您的備份或暫存區實際包含哪些內容。現在花一點時間進行驗證,可以省下日後數小時的重建時間。.

結論:將 Git 中的遺失檔案與仍存在的副本進行配對

最好的 Git 遺失的檔案 解決方案取決於遺失的版本仍保留在何處。對於受追蹤的檔案,請使用索引或提交紀錄;對於遺失的提交,請使用提交日誌;至於 Git 從未儲存過的內容,則請使用編輯器歷史紀錄或備份。.

若這些檢查確認確實發生儲存資料遺失,, Magic Data Recovery 這是一項合理的 Windows 選項,因為它能處理超出 Git 記錄範圍的刪除、格式化及檔案系統錯誤。請依照 已刪除檔案復原指南, 將候選方案儲存至其他位置,並在將其還原至您的專案之前驗證程式碼。.

支援 Windows 7/8/10/11 和 Windows Server

常見問題

1. Git 能否還原從未提交過的檔案?

有時候。Git 可能仍會保留您已標記為待提交的內容 git add 或儲存於暫存區中。若 Git 從未儲存過該遺失的版本,請檢查編輯器的本地歷史紀錄、備份檔及雲端副本。在實際刪除後,磁碟復原或許有所幫助,但無法重建僅存在於記憶體中的程式碼。.

2. 如何在不重置所有設定的情況下,恢復已刪除的檔案?

若要執行未排程的刪除,請使用 git restore -- 檔案路徑. 若您已預先安排刪除作業,請從 HEAD 與 --已標記 --工作樹. 若要永久刪除檔案,請找出包含該檔案的較早版本,並僅還原該路徑。在替換任何內容之前,請先保留較新的內容。.

3. git reflog 能否還原未提交的變更?

Reflog 記錄的是參考變動,而非每次編輯的完整歷史紀錄。它有助於在執行 reset、rebase 或 amend 之後,找出遺失的提交。若要查找未提交的內容,請改為檢查索引、暫存區、存留的 blob 或編輯器歷史紀錄。僅靠 Reflog 無法還原 Git 從未儲存過的版本。.

4. 執行 `git clean -fd` 後,還能恢復檔案嗎?

可能透過編輯器歷史紀錄、備份、雲端副本或磁碟復原來實現。此指令會移除未被追蹤的檔案和目錄。若 Git 從未儲存過其內容,則無法透過歷史紀錄將其還原。請停止對受影響的磁碟進行寫入操作,檢查其他副本,並僅在裝置保持穩定時才進行掃描。.

5. 為何在檔案缺失的情況下,`git pull` 仍顯示「已更新」?

Pull 會整合遠端歷史紀錄;當無需整合新的提交時,它並不保證會重建每個缺失的工作樹檔案。請檢查 git status 並從相應的來源還原已追蹤的刪除項目。同時請檢查您的當前分支、稀疏檢出設定,以及該遺失的資料夾是否屬於子模組。.

6. Git 會將「lost-found」資料夾中的檔案存放於何處?

對於標準儲存庫而言,, git fsck --lost-found 將懸空的復原物件寫入 .git/lost-found/commit/ 或 .git/lost-found/other/. Blob 條目包含檔案內容,但通常沒有原始檔案名稱。在連結的工作樹中,請先找出實際的 Git 元資料目錄,再尋找這些資料夾。.

7. Magic Data Recovery 能否還原整個 Git 儲存庫?

它或許能從受影響的儲存裝置中恢復倖存的檔案,但檔案恢復並不能保證儲存庫完整無缺。Git 還需要一致的物件、參照和元資料。請先將原始檔案恢復至另一顆硬碟,驗證其內容,若元資料仍不完整,則應從已知無誤的儲存庫重新建置。.

8. 還原到較舊的 Git 版本是否能恢復我最新的編輯內容?

不。從提交還原會還原該提交所包含的版本;從索引還原則會還原已暫存的版本。這兩種方式都不會自動包含後續未暫存的編輯內容。請分別在編輯器歷史紀錄、暫存區或其他已儲存的副本中尋找這些變更,然後比較還原後的版本。.

Jason 是一位擁有超過 15 年實務經驗的資料復原與技術支援專家。 他長期與第一線使用者密切合作,處理棘手的資料遺失案例,並針對誤刪資料、磁碟格式化、檔案系統損毀、分割區遺失、系統故障及其他緊急資料復原情況,提供實用的復原解決方案。其專業領域還涵蓋備份與還原、檔案修復及災難復原,並特別注重提供安全、可靠且技術上精準的指導。.