提交恢复
这里说的恢复，主要是从commit的恢复，从index恢复到working，我们可以使用
git checkout -- <path>
这里说的恢复，我们按照下面三种的case来说明。
仅仅恢复数据，但是不影响HEAD checkout
git checkout <commitId> <path>
通过执行上面这个命令，可以把commitId对应的提交的文件恢复掉，但是不会影响HEAD
commit回滚 reset
git reset <commitId>
如下图:
这里会改变HEAD的指向，执行这个命令的时候，有三个选项
- git reset --soft <commitId> 这里只会改变HEAD的指向，但是不会影响index和working
- git reset --mixed <commitId> 这里会改变HEAD的指向，而且会影响index
- git reset --hard <commitId>这里会改变HEAD的指向，而且会影响index和working
在执行reset的时候，类似上图，我们把reset到b提交后，a提交其实是没有任何的指向的，这个时候如果我们提交的话，就会导致我们在git log后都找不到a提交，而且如果通过git push -f（因为比remote靠后，所以需要强制push），也会造成远程的a提交被覆盖掉。
如果只是在本地reset后，但是还是想找到之前的commit，我们可以在利用git reflog来找到，具体的使用方法我们后面会提到。
如果已经push到remote了，我们可以参考 http://blog.sina.com.cn/s/blog_66cd08930102x0ln.html
反向提交 revert
在实际工作中，我们使用的git flow的模型，是一直维护一个master的分支，每次开发，我们都会新建一个branch的分支，开发好后直接会merge到master中。但是如果我们发现某一次merge到master分支的提交是错误的，我们希望回滚应该怎么办呢。
如下图：
branch1的变更是不需要的，所以我们需要把这些变更回滚掉。
- 如果我们有master的权限
如果我们有master分支的权限，我们可以直接把reset到c，然后通过
git push -f
就可以把代码回滚到c提交。
-
很多情况下，我们是没有master权限的，我们只能通过新建分支，然后通过这个分支重新合并到主干才能达到这个要求。如果这个时候我们在新分支中使用reset，但是在合并骨干的时候会出现没有更新的情况。因为master指向的提交是在branch2指向提交之后，所以合并的时候并不会按照我们所愿，把e和f的内容去掉。如下图：
C2766A7D-F222-428A-9A46-3D9247B4F8CF.png
这个时候，我们就可以使用
git revert d -m 1
这个操作其实是进行一个逆向的提交，并且生成一个新的提交g，其实这里g和c是同一个内容，这个时候master在合并branch2的时候，就会通过fast-forward，master直接指向了g提交，这样就达到了我们master分支回滚的需求。
