08 - 救命的后悔药（找回丢失的代码）

“ 新来的实习生把自己做了一个月的功能给覆盖了，向我求救，要不要帮他？——编程三分钟”

新来的实习生【悲郭】因为不太熟悉git的使用，总是把自己的代码给弄丢了，这次好了，把辛苦写了一个月的功能全弄丢了。还好我力挽狂澜帮他恢复了过来。下面我们分两种代码丢失的场景情况来讨论。

恢复曾今提交过的记录

你使用了git reset --hard commit—id命令，将工作区的提交穿越到你指定的commit里，这个时候你会发现git log根本没有记录这之后的提交记录，像下面这个样子，你是不是会非常着急呢？

不要太紧张，Git提供了一个命令git reflog用来记录你的每一次改变目录树的命令，使用好他就可以很方便的恢复你的提交：

刚才我们提到一个关键字目录树，那么什么是目录树呢？

我们的主线往往是一根直线，多一个分支相当于多一个分叉，无数分支纵横交错就像一颗树状的结构，所以我们称之为目录树。commit rebase reset merge这些都是改变目录树的操作。

1. 这个恢复丢失代码方法也只有存在改变目录树的操作才恢复的回来

2. git log 是一样的，也可以看到所有分支的历史提交，不一样的是看不到已经被删除的commit 记录和 reset rebase merge 的操作 我们可以看到git reflog前面的就是`commit id
   ```，现在我们就可以用 之前介绍过的方法 来回滚版本了

再举一个例子，通过上面的git reflog打印出来的记录，我们记住最后两个提交的commit id和提交说明分别是00：50和18:51，我们来使用git reset --hard commit—id去到18:51,这个时候 00:50的提交就没有了，就算git log也看不见。然后我们再通过我们记住的commit id就可以回滚回去了！


上图的步骤为：

• 根据git reflog返回的结果，用git reset --hard commit_id回退到856a740这个版本

• git log -1看近一行的日志，可以看到目前回到了856a740这个版本，也就是上一个版本

• 再根据git reflog的结果，用git reset --hard 35b66ed跑回最新的这次提交

• git log -2看到两次提交的日志，我们就这么再穿梭过来了，就是这么爽

但是我们如果只是想把此提交给找回来，恢复他，那还是不要用reset的方式，可以用git cherry-pick commitid单独取一个commit到当前分支或者用merge来做合并。

恢复忘记提交的记录

如果你的代码文件没有commit过，就被手贱删除掉了或者也是被reset --hard的时候搞没了。
这就不仅仅是用一个git reflog命令就可以简单找回来的，但只要你以前有做过add的操作把他放到过暂存区，我们就可以把他找回来。什么？你连add都没有操作过那就只能开始准备新一轮的面试了。
先来创建一个灾难现场。

• 创建一个叫lose_file.txt的文件并写入内容my lose message，并使用git add把他加到暂存区

• 用git reset --hard 35b66ed8用丢弃一切修改的方式来使现在的工作区恢复到35b66ed8版本，因为还没提交所以也就是恢复到当前的（head）版本。

• 我们用status和ls再看，这个叫lose_file.txt的文件真的没了，完蛋了,第一反应使用刚刚学到的命令git reflog会发现根本就不好使，那现在只能去准备跑路了呢？不慌，让我们进入下一节

我们来看看git底层原理

核心命令：git fsck --lost-found,他会通过一些神奇的方式把历史操作过的文件以某种算法算出来加到.git/lost-found文件夹里，输出的记录就像下面这个样子。

我们可以看到这里有blob、commit、tree类型的数据，还有tag等类型的。他们是什么含义呢？
来，我们都是大神当然要学学git底层存储方式，如下图：

• commit数据结构在每次提交之后都会生成一个，当我们进行commit之后，首先会创建一个commit组件，之后创建一个tree组件，把所有的文件信息都储存在里面,每个blob代表一个文件，都可以在tree里找到

• blob组件并不会对文件信息进行存储，而是只对文件的内容进行记录，文件信息存储在tree里

言归正传，我们来看看怎么恢复刚刚git reset --hard后，不见了的lose_file.txt文件。
在上面执行完git fsck --lost-found命令，返回的第一行blob我们使用git show命令来看看他的内容

正好内容就是lose_file.txt原本的内容，就是我们丢失的文件内容，这样就找回来了！ 

我们再来看看上图中的commit和commit下的tree内容，可以看到他们之间的层级关系如下：

• 用git cat-file -p可以看到commit的内容，可以选择把这个commit合并到我们的分支里，还是reset merge rebase cherry-pick这些命令来合commit

• git ls-tree列出tree下面的文件名和id的记录信息，然后就可以根据blob的id来恢复文件了

后记

如果你发现执行git fsck --lost-found的输出也找不到你想要的，那么只能祭出终极命令来输出近期修改的文件了，如下：

• 这里用find .git/objects -type f | xargs ls -lt | sed 3q这个命令，他的含义是查找.git/objects文件夹下的普通文件 按照时间排序后 打印在终端里 sed 3q 是打印3行 sed 100q 是打印100行，随你喜欢。

• git cat-file -t
7f5965523d2b9e850b39eb46e8e0f7c5755f6719 就能看见文件类型 把最后一个/去掉 复制从objects/ 后面的所有东西放在-t后面

• git cat-file -p id就能看见文件内容，是不是很爽，你再用高超的linux技巧操作一下，就可以批量打印出全部文件的类型啦

小结

经过一番操作以后实习生【悲郭】终于不用再背锅了，我们来总结一下：
1. 提交过的就用命令git reflog来查询提交记录找回
2. 未提交但是git add过的就用git fsck --lost-found来生成丢失文件记录来找回。
3. 没找回成功就用用find .git/objects -type f | xargs ls -lt | sed 3q这个命令来输出近期修改的文件找回。

代码恢复的前提是要保证你的项目根目录下.git文件夹是完整的，要是手动删除了里面的一些东西那就真完了。还要保证一点，你的代码以前是有过git追踪，最少add过！