[[403956]]

前言：

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

給大家分享一下自己的實(shí)操。

恢復(fù)步驟記錄：

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

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

git fsck --lost-found 

一般來說有很多的搜索結(jié)果，多達(dá)上百條，這個(gè)時(shí)候我們可以去進(jìn)行去排除一些用不到的數(shù)據(jù)。

我們來看看這些數(shù)據(jù)類型的含義：

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

trees 每個(gè)tree代表了一個(gè)目錄的信息，包含了此目錄下的blobs，子目錄(對應(yīng)于子trees)，文件名、路徑等元數(shù)據(jù)。因此，對于有子目錄的目錄，git相當(dāng)于存儲(chǔ)了嵌套的trees。

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

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

查看每個(gè)id下的代碼文件是否是需要恢復(fù)的

git stash apply  指定id 

如下所示：

但是不是一次就可以找到對應(yīng)的id，所以當(dāng)查看到代碼文件是有問題的時(shí)候，我再復(fù)位清除一次代碼文件

git reset --hard 

直至找到對應(yīng)的文件

結(jié)語

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

作者：良知猶存，白天努力工作，晚上原創(chuàng)公號(hào)號(hào)主。公眾號(hào)內(nèi)容除了技術(shù)還有些人生感悟，一個(gè)認(rèn)真輸出內(nèi)容的職場老司機(jī)，也是一個(gè)技術(shù)之外豐富生活的人，攝影、音樂 and 籃球。關(guān)注我，與我一起同行。

本文轉(zhuǎn)載自微信公眾號(hào)「羽林君」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系羽林君公眾號(hào)。