reflog 真是个贴心小棉袄
写在前面
上篇写的是数据删除，这篇的主题，就是数据恢复。学会了这俩，可以更放心大胆的去耍了。
reflog 是什么？
reflog,可以分为两个单词，Reference log，引用日志。当本地仓库中的引用发生移动时，reflog 都会记录下这个移动的行为，跟部移动记录仪差不多。
关于引用是什么？引用的移动是什么？这哥们又是怎么记录这种移动的呢？这些问题先放着，我们先在我的测试项目中，执行下 git reflog 来瞅瞅。
因为做过很多操作，有很多条记录，数据太多，你可能一下看不懂，所以来化繁为简分析一下，单条记录中每个数据都代表着什么？
41b9778是 commit 的 SHA1 值,需要特别注意，它是移动后的 commit。HEAD@{2}是标识这是 HEAD 指针2个移动前的指向内容（从当前往回数第3个操作），也就是上面的41b9778。commit是表示造成这个移动的原因，是进行了 commit 操作。创建11.txt文件表示操作的内容，commit 操作对应的就是 commit message。
单条记录明白之后，再看整体的截图，一目了然。很轻松就知道，我用 Git 到底对这个项目做了什么。
- 引用是什么？
- 引用的移动是什么？
- 这哥们又是怎么记录这种移动的呢？
现在你对这三个问题，有答案了吗？
在上面那副图中，引用指的就是 HEAD 指针；引用的移动就是 HEAD 指针的移动；通过记录操作的命令，操作的次序，操作的内容，操作后的提交信息，来记录这整个操作引起的指针移动行为。
现在我要再问几个问题：
- 引用除了HEAD 指针，还有其他的吗？
- 如果有，它们是什么？会被 reflog 记录吗？
- 如果能被记录，怎么查看？
Reference logs, or “reflogs”, record when the tips of branches and other references were updated in the local repository.
这句话是 git-reflog 官方文档 上对 reflog 的描述，很明确的表达记录的是 “branches and other references（分支或者其他引用）”的更新变化。
所以很明显，引用指的不仅仅是 HEAD 指针，还有分支指针。
git reflog <ref>
<ref> 默认的是 HEAD 指针，如果我们想查看其他的引用，换成对应的内容就可以。
//查看 master 分支指针的移动记录
git reflog master
//查看 feature/test 分支指针的移动记录
git reflog feature/test
reflog 的治愈力
上篇博客讲过，这是一个比较治愈的命令，为什么呢？因为在误操作丢失数据之后，大多能通过它找回来。
例如：
- 误删了未合并的分支
- reset --hard 的时候一不小心HEAD^写成 HEAD^^^，历史倒退太多了
- 等等，各种失误 & 只是任性的只是想恢复了
这些涉及到指针移动的都可以，全部通过 reflog 找回来。
恢复的流程基本都一样：
第一步：git reflog找回错误操作前的 commit。
第二步：视你自己的需要，对这个提交做点什么。
下面模拟一下，reset 操作和误删分支的恢复流程，感受一下对误操作造成的心灵创伤，reflog 具有的强大治愈力。
- 恢复
reset --hard
1.先模拟一个reset --hard操作。
2.找到 reset 操作前的 commit
3.git reset --hard <commit> 直接恢复操作前的历史。这一步使用 git reset --hard HEAD@{1}也可以，都是一个意思。
- 恢复
git branch -D <branch>
1.先模拟一个git branch -D <branch操作。
2.删除操作不会导致 HEAD 指针变化，而且删除之后 feature/test 指针也没了，怎么办呢，这个就要从 HEAD 指针的记录里面翻翻看，找到上次在这个分支上的操作记录。删除分支如果是最新操作过的，一般很好找到。
找到 checkout 的操作，很容易分析出，feature/test 的指针指向的提交是 41b9778。
3.git checkout <commit> -b <branch> 将该提交检出为一个新分支，新分支起名为 feature/test ，就相当于误删分支的恢复了。
写在最后
以上就是本博客的全部内容了，记录的是我自己对 reflog 的理解和使用，希望能带给你们帮助， 如果想知道 reflog 更多的使用方法，小伙伴们自己去看 官方文档 呐，我就不一一说了。
另外，在学习 reflog 的过程中，我有了一个疑问：
丢失的 commit 真的丢了吗？
显然是没丢的，不然谈何恢复，但是它在哪存放着呢？我会一直存在吗？我怎么知道它还在不在呢？
这个疑问，下篇博客《Git-丢失的 commit 是真的消失了吗？》 已经解决，敬请关注，see you next blog～
欢迎订阅我的Git系列文章
- 01. 请回答：Git是什么？
- 02. Git常用命令一日游活动
- 03. Git三大特色之Branch(分支)
- 04. Git三大特色之Stage(暂存区)
- 05. Git三大特色之WorkFlow(工作流)
- 06. Git-你好, HEAD 同学
- 07. Git-用 cherry-pick 挑好看的小樱桃
- 08. Git-rebase 黑魔法之打造完美的线性历史
- 09. Git-rebase 黑魔法之打磨 commit 颗粒度
- 10. Git-少年，你想学回滚吗？想撤销文件修改吗？
- 11. Git-移动记录仪 & 贴心小棉袄 reflog
- 12. Git-丢失的 commit 是真的消失了吗？
- 13. Git-叹为观止的 log 命令 & 其参数
- 14. Git-送娃子们一本关于如何自学 Git 的秘籍
欢迎关注博主的微信公众号，快快加入哦，期待与你一起成长！
