给大家分享一下自己的实操。
恢复步骤记录:
其实整体步骤不是很多,但是中间去一个个测试那个版本是否是你需要的比较耗费时间。首先,我们当使用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 篮球。关注我,与我一起同行。
本文转载自微信公众号「羽林君」,可以通过以下二维码关注。转载本文请联系羽林君公众号。