[[403956]]

前言：

在使用git時候我們會臨時切換一些分支，而切換時候你本地會有一些更改了的代碼，但是這些代碼還沒有寫完整，所以我們一般會進行git stash 本地保存一下。然后等后面代碼切換回來之后，再 git stash apply ,代碼恢復之后我們會把這些臨時本地保存代碼stash記錄清除掉，但是清除就可能出現誤操作。我有次就遇到了誤刪，因為stash list里面有五六個版本，而且很多對應了一個commit。這個時候我們怎么找回誤刪的的代碼呢?

給大家分享一下自己的實操。

恢復步驟記錄：

其實整體步驟不是很多，但是中間去一個個測試那個版本是否是你需要的比較耗費時間。首先，我們當使用git stash drop和git stash pop時候，git stash list是看上去不可見了，但是實質上git并沒有刪除這個文件，就是你的引用關系被移除了，你需要去搜索那條對應被丟棄的commit下的代碼。

顯示出所有不可訪問的對象

git fsck --lost-found 

一般來說有很多的搜索結果，多達上百條，這個時候我們可以去進行去排除一些用不到的數據。

我們來看看這些數據類型的含義：

blobs 每個blob代表一個(版本的)文件，blob只包含文件的數據，而忽略文件的其他元數據，如名字、路徑、格式等。tags tag用于給某個上述類型的對象指配一個便于開發者記憶的名字, 通常用于某次commit。

trees 每個tree代表了一個目錄的信息，包含了此目錄下的blobs，子目錄(對應于子trees)，文件名、路徑等元數據。因此，對于有子目錄的目錄，git相當于存儲了嵌套的trees。

commits 每個commit記錄了提交一個更新的所有元數據，如指向的tree，父commit，作者、提交者、提交日期、提交日志等。每次提交都指向一個tree對象，記錄了當次提交時的目錄信息。一個commit可以有多個(至少一個)父commits。

經過分析我們知道commit類型的后面跟著的id是我們可以用到的，但是搜索出來的列表不是按照時間來進行排序的，這樣就給我們又造成了一些選擇的負擔，好在雖然搜索結果很多，但是commit類型的結果數量還是可以接受的，所以我用了一個笨辦法，我把所有搜索到的結果都放到一個文件中，然后只保留下commit類型的數據。

查看每個id下的代碼文件是否是需要恢復的

git stash apply  指定id 

如下所示：

但是不是一次就可以找到對應的id，所以當查看到代碼文件是有問題的時候，我再復位清除一次代碼文件

git reset --hard 

直至找到對應的文件

結語

這就是我分享的某次git誤刪stash文件之后的恢復工作，如果大家有更好的想法和需求，也歡迎大家加我好友交流分享哈。

作者：良知猶存，白天努力工作，晚上原創公號號主。公眾號內容除了技術還有些人生感悟，一個認真輸出內容的職場老司機，也是一個技術之外豐富生活的人，攝影、音樂 and 籃球。關注我，與我一起同行。

本文轉載自微信公眾號「羽林君」，可以通過以下二維碼關注。轉載本文請聯系羽林君公眾號。