Git进阶系列 | 8. 用Reflog恢复丢失的提交
Git是最流行的代码版本控制系统，这一系列文章介绍了一些Git的高阶使用方式，从而帮助我们可以更好的利用Git的能力。本系列一共8篇文章，这是最后一篇。原文：Using the Reflog to Restore Lost Commits[1]
“Reflog”是Git不太为人所知的特性之一，但可能非常有用。有些人把它称为“安全网”，而我喜欢把它看作Git的“日记”，因为Git用它来记录HEAD指针的每次移动(例如，每次提交、合并、rebase、cherry-pick、reset等)。Git会将操作记录在Reflog中，使它成为一个有价值的日志，当出现问题时，这是一个很好的起点。
在“Git进阶”系列的最后一部分，我将解释git log和git reflog之间的区别，并展示如何使用reflog来恢复已删除的提交和已删除的分支。
Git进阶系列:
git log和git reflog有什么区别?
在之前的文章中，我建议使用git log命令检查事件并查看提交历史，这正是它的工作。它可以显示当前的HEAD及其祖先，即父提交，下一个父提交，等等。git log通过递归打印每个提交的父节点来回溯提交历史，这是代码库的一部分，这意味着在push、fetch、pull之后这些信息都会被复制。
另一方面，git reflog是一个私有的、与工作空间相关的记录。它不遍历祖先列表。相反，它显示一个有序列表，包含HEAD过去所指向的所有提交。这就是为什么可以把它看作某种“撤销历史(undo history)”，就像在文字处理器、文本编辑器等中看到的那样。
技术上来说，这个本地记录不是代码库的一部分，它与提交分开存储。Reflog是.git/logs/refs/heads/中的一个文件，用来跟踪每个分支的本地提交。Git的日志通常会在90天后被清理(这是默认设置)，但是可以轻松调整Reflog的过期日期。要将过期时间更改为180天，只需输入以下命令:
$ git config gc.reflogExpire 180.days.ago
仓库配置文件(.git/config)包含变量reflogExpire，值为180.days.ago
或者可以设置Reflog永不过期:
$ git config gc.reflogExpire never
提示: 记住，Git区分了代码库的配置文件(
.git /config)、每个用户的全局配置($HOME/.gitconfig)和系统全局设置(/etc/gitconfig)。要为用户或系统调整Reflog的过期时间，请在上面所示的命令后面添加--system或--global参数。
好了，现在我们有了足够的理论背景知识，接下来可以展示如何使用git reflog来纠正错误。
恢复删除的提交
想象一下下面这个场景: 在查看了提交历史之后，我们决定删除最后两次提交。勇敢的执行了一次git reset后，两个提交从提交历史中消失了……过了一会儿，我们发现犯了个错误，我们丢失了有价值的更改，完蛋了!
真的要从头再来吗？不。换句话说，保持冷静，利用git reflog！
所以，让我们尝试把事情搞砸，在现实生活中真的犯一下错。下图展示了我们最初在Tower中的提交历史:
我们想要删除两个提交，并将“Change headlines for about and imprint”提交(ID: 2b504bee)作为master分支上的最后一个修改。我们需要做的就是将哈希ID复制到剪贴板，然后在命令行中使用git reset并输入哈希:
$ git reset --hard 2b504bee
瞧。提交已经消失。现在，我们假设这是一个错误，并查看Reflog来恢复丢失的数据。在终端中输入git reflog查看日志:
有没有注意到所有条目都是按时间顺序排列的，这意味着顶部是最近的（也就是最新的）提交。如果仔细看，会注意到几分钟前致命的git reset操作就在顶部。
日记似乎起作用了，这是个好消息。因此，我们用它来撤销最后一个操作，并在执行reset命令之前恢复状态。与前面一样，将哈希ID(在这个特定示例中为e5b19e4)复制到剪贴板，再次使用git reset，这完全有效。但在本例中，我将基于旧状态创建一个新分支:
$ git branch happy-ending e5b19e4
再看看图形化Git客户端:
如你所见，已经创建了新的happy-ending分支，包含了之前删除的提交。太棒了，什么都没丢！
接下来看看另一个示例，用Reflog来恢复整个分支。
恢复删除的分支
下面的示例和第一个场景类似，我们要删除一些东西，只是这一次要删除的是整个分支。也许你的客户或团队领导告诉你要摆脱一个特性分支，也许你自己想要进行清理。糟糕的是，有个提交(图中的C3)没有被包含在任何其他分支中，所以肯定会丢失数据:
我们来实际执行这个操作，稍后再恢复分支:
在删除分支feature/login之前，需要先切换出来。(正如截图中所示，这是当前的HEAD分支，不能在Git中删除HEAD分支。)所以，我们要切换分支(到master)，然后删除feature/login:
好吧，假设我们的客户或团队领导改变了主意，现在又需要feature/login分支(包括它的提交)了，怎么办？
看看Git的日记:
$ git reflog
776f8ca (HEAD -> master) HEAD@{0}: checkout: moving from feature/login to master
b1c249b (feature/login) HEAD@{1}: checkout: moving from master to feature/login
[...]
我们又很幸运，最后一项显示了从feature/login到master的切换。我们尝试返回到之前的状态，将哈希ID b1c249b复制到剪贴板，接下来，基于期望的状态创建一个名为feature/login的分支:
$ git branch feature/login b1c249b
$ git branch -vv
feature/login b1c249b Change Imprint page title
* master 776f8ca Change about title and delete error page
太棒了，分支死而复生，仍然包含了我们认为已经丢失的有价值的提交:
如果使用像Tower这样的桌面GUI，可以简单的按下CMD+Z来撤销最后一个操作，就像文本编辑器或文字处理器一样。
保持冷静，保证记录
Git的Reflog可以成为真正的救星！如你所见，很容易将丢失的提交甚至整个分支从坟墓中带回来，只需要在reflog中找到正确的哈希ID，其他都是小菜一碟。
如果想更深入了解高级Git工具，可以免费查看“Advanced Git Kit[3]”: 这是关于分支策略、交互式Rebase、Reflog、子模块等主题的短视频集合。
本文是“Git进阶”系列的最后一部分，希望你喜欢这些文章。编码快乐！
References:
[1] Using the Reflog to Restore Lost Commits: https://css-tricks.com/using-the-reflog-to-restore-lost-commits/
你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。
微信公众号：DeepNoMind
