操作git rebase或git reset 命令看上去很简单，但是操作过后后悔了，怎么办？
由于git rebase或git reset更改/重写了 git commit log，因此唯一的返回方法是删除所有内容，然后重新 clone 存储库以重新开始。可能您在读完本文前，都是这样做的！
在本文中，我将向您展示如何使用reflog（以及其他一些优雅的快捷方式）撤消某些改变历史的动作，并返回正确的时间表！
设置环境
如果您只想阅读示例，则可以跳到下一部分。但是，如果您想在自己的终端上按照示例操作，请在终端中作为命令运行以下每一行以设置演示库：
mkdir reflog-demo && cd reflog-demo && git init
echo "file 1 content" > file1.txt && git add . && git commit -m "add file1"
echo "file 2 content" > file2.txt && git add . && git commit -m "add file2"
git checkout -b my-new-branch
echo "new branch file content" > newBranchFile.txt && git add . && git commit -m "add newBranchFile"
git checkout master
echo "file 3 content" > file3.txt && git add . && git commit -m "add file3"
git checkout my-new-branch
仓库的 commit 信息如下（使用git log --oneline --graph --all 查看）：
有一个master分支，其中包含 3 个文件，每个文件都通过一个单独的 commit 添加到 git 中。还有一个单独的my-new-branch分支。该分支还具有 master 分之前两个文件，但随后与 master 分离，并拥有自己的第三个文件newBranchFile.txt。
这是期望的状态。在下面的示例中将其弄乱时，我们的目标是使存储库恢复到此状态。
使用 reflog 重置引用
假设我们处于my-new-branch分支上，并且 rebase master：
我们意识到这是一个错误！rebase 操作后，代码逻辑可能不对了。在 rebase 过程中可能存在一些奇怪的合并冲突，并且一切都变得混乱了。无论哪种情况，我们都希望代码能像以前一样，但是
新的 git log 显示如下，原来的 commit 606d45d 不见了，我们怎么回去呢？
我们可以删除所有内容并重新克隆，但是我们可能没有最新的 my-new-branch 副本。 我们需要在旧提交的基础上手动创建一个新分支，然后重新添加/删除那里的文件，修改里面的内容，但是很麻烦！
相反，可以尝试运行git reflog以查看历史记录中的有用信息：
git reflog显示了我们当前工作的HEAD所在的所有地方，包括使用破坏性命令（如git reset和git rebase）删除的提交。只需选出进行破坏性更改之前的 commit id，对gitrevision编号（带有花括号的编号）进行硬重置，然后将所有内容重置为恢复基准之前的状态！
本环境中的gitrevision是 3 和 4 都可以，我们 gitrevision 编号 3：
git reset --hard HEAD@{3}
在执行此命令后，git log 恢复到了目标状态（即 rebase 误操作前的状态），如下图：
重置到 ORIG_HEAD
如果觉得reflog输出有点令人困惑，而且很难准确的确定要返回到哪个 reflog。
确实这样！很庆幸，又一个非常简单的方式：
git reset --hard ORIG_HEAD
**ORIG_HEAD**会自动指向最新破坏性更改之前的状态，因此我们可以轻松地撤消最新的变基或使用单个命令进行重置！
在上面的示例中运行git reset --hard ORIG_HEAD与在上面的示例中运行git reset --hard HEAD@{3}完全相同，而无需查找特定的修订版！
重置到相对时间点
🌟🌟🌟 非常棒的方法！
重置为ORIG_HEAD很棒，但是如果我们真的陷入了破坏性变化的困境，那该怎么办。让我们以上一个示例为基础，并向其添加更多步骤：
git rebase master
git reset --hard HEAD~2
git commit --amend -m 'shablagoo!'
一顿操作猛如虎，然后 git log 的状态如下：
文件夹内容如下：
提交全部乱序，还导致文件缺失。我们如何才能撤消呢？？？我们进行了多次破坏性的更改，因此ORIG_HEAD无法正常工作。我们可以检查git reflog，但是发生了太多更改，可能很难找到正确的 gitrevision 编号。
试试：
git reset --hard HEAD@{15.minutes.ago}
🤔️ 为什么是 15 分钟？（这不是重点！！！）
我们可以简单估算下时间或者从集成开发环境的 history 中找到合理的时间点，然后将 git 的分支回到过去的某个时间点！ 演示中我的 terminal 每次都会打印当前命令的时间点，比较容易找到错误发生时的时刻。
然后 git log 信息恢复到了之前的状态：
