⑴它涉及的只是 HEAD 的改变。在你切换分支、用 git mit 进行提交、以及用 git reset 撤销 mit 时，HEAD 会改变，但当你用 git checkout -- 《bad filename》 撤销时（正如我们在前面讲到的情况，HEAD 并不会改变 — 如前所述，这些修改从来没有被提交过，因此 reflog 也无法帮助我们恢复它们。
⑵git reflog 不会永远保持。Git 会定期清理那些 “用不到的” 对象。不要指望几个月前的提交还一直躺在那里。
⑶你的 reflog 就是你的，只是你的。你不能用 git reflog 来恢复另一个开发者没有 push 过的 mit。
⑷那么…你怎么利用 reflog 来“恢复”之前“撤销”的 mit 呢？它取决于你想做到的到底是什么：
⑸如果你希望准确地恢复项目的历史到某个时间点，用 git reset --hard 《SHA》
⑹如果你希望重建工作目录里的一个或多个文件，让它们恢复到某个时间点的状态，用 git checkout 《SHA》 -- 《filename》
⑺如果你希望把这些 mit 里的某一个重新提交到你的代码库里，用 git cherry-pick 《SHA》
⑻利用分支的另一种做法
⑼场景： 你进行了一些提交，然后意识到你开始 check out 的是 master 分支。你希望这些提交进到另一个特性（feature分支里。
⑽方法： git branch feature， git reset --hard origin/master， and git checkout feature
⑾原理： 你可能习惯了用 git checkout -b 《name》 创建新的分支 — 这是创建新分支并马上 check out 的流行捷径 — 但是你不希望马上切换分支。这里， git branch feature 创建一个叫做 feature 的新分支并指向你最近的 mit，但还是让你 check out 在 master 分支上。
⑿下一步，在提交任何新的 mit 之前，用 git reset --hard 把 master 分支倒回 origin/master。不过别担心，那些 mit 还在 feature 分支里。
⒀最后，用 git checkout 切换到新的 feature 分支，并且让你最近所有的工作成果都完好无损。
⒁及时分支，省去繁琐
⒂场景： 你在 master 分支的基础上创建了 feature 分支，但 master 分支已经滞后于 origin/master 很多。现在 master 分支已经和 origin/master 同步，你希望在 feature 上的提交是从现在开始，而不是也从滞后很多的地方开始。
⒃方法： git checkout feature 和 git rebase master
⒄原理： 要达到这个效果，你本来可以通过 git reset （不加 --hard， 这样可以在磁盘上保留修改 和 git checkout -b 《new branch name》 然后再重新提交修改，不过这样做的话，你就会失去提交历史。我们有更好的办法。
⒅git rebase master 会做如下的事情：
⒆首先它会找到你当前 check out 的分支和 master 分支的共同祖先。
⒇然后它 reset 当前 check out 的分支到那个共同祖先，在一个临时保存区存放所有之前的提交。
⒈然后它把当前 check out 的分支提到 master 的末尾部分，并从临时保存区重新把存放的 mit 提交到 master 分支的最后一个 mit 之后。