目录
1、--soft回退说明
2、--mixed回退说明
3、--hard回退说明
4、总结
以前面文章中的示例为例，当我准备在V4版本，回退到V3版本的时候，分支中的提交和工作目录中文件的状态，如下图所示：
我们分别执行了三种回退方式：
git reset --soft HEAD^：温柔的回退。
git reset --mixed HEAD^：中等回退。
git reset --hard HEAD^：强硬的回退。
（我们从英文中就可以看出，一个比一个回退的多。）
下面我们一一进行总结。
1、--soft回退说明
当我在V4版本的时候，执行git reset --soft HEAD^命令回退到V3版本。
Git中发生的变化如下图所示：
依据上图，理解一下发生的事情：本质上就发生了，把HEAD指针指向了V3版本。而工作区和暂存区中的readme.txt文件是没有做任何变动的。
所以你查看本地版本库中的readme.txt文件是V3版本，工作区和暂存区中的readme.txt文件是V4版本。
就等于回滚到了git commit之前的状态。
（我前面文章中有详细的演示）
拓展：
当我继续修改readme.txt文件之后，再次提交，会在V3版本之上在创建一个新的commit提交，并移动HEAD指针指向的分支来使其指向该commit提交，这样依次提交下去，如下图所示：
如果我们使用git log命令查看本地版本库的历史提交信息的时候，就不会出现V4版本提交的信息。会是V1、V2、V3、V5。（我们从前面文章中已经演示了）
但是V4版本是不会在Git中删除的，会永远的存储在Git的本地版本库中。我们可以使用git reflog命令，可以查看该V4版本的提交信息。
提示：只要是本地版本库中
HEAD有过的变化，那么git reflog命令就能够显示出来。
（关于这点，下面同理，所以下面就不说了。）
2、--mixed回退说明
当我在V4版本的时候，执行git reset --mixed HEAD^命令回退到V3版本。
Git中发生的变化，如下图所示：
理解一下发生的事情，我们可以看到上图中，完成了两步操作：
- 把HEAD指针指向了
V3版本（也就是版本库回退了）。把暂存区中的
readme.txt文件也回退到了V3版本。而只有工作区中的readme.txt文件内容没有变化。
这说明git reset --mixed命令比git reset --soft命令，多回退了暂存区中的内容。
就等于回滚到了git commit和git add之前的状态。
（我前面文章中有详细的演示）
提示：因为
--mixed参数是git reset命令的默认选项，也就是不写任何参数就默认使用--mixed参数。即git reset HEAD^等同于git reset --mixed HEAD^命令
3、--hard回退说明
当我在V4版本的时候，执行git reset --hard HEAD^命令回退到V3版本。
Git中发生的变化，如下图所示：
理解一下发生的事情，我们可以看到上图中，完成了三步操作：
- 把HEAD指针指向了
V3版本（也就是版本库回退了）。把暂存区中的
readme.txt文件也回退到了V3版本。把工作区中
readme.txt文件的修改也复原了。所以执行完git reset --hard HEAD^命令，是完全回退一个版本。
此时工作区、暂存区、本地版本库中的文件状态都是一致的，都是V3版本。
就等于回滚了一个“编辑文件，添加到暂存区，提交版本库”的整个流程。
（我前面文章中有详细的演示）
4、总结
必须注意：
--hard参数是git reset命令唯一的危险用法，是能够使Git会真正地销毁数据的仅有的几个操作之一。
其他任何形式的git reset操作都可以轻松撤消，但是--hard选项不能，因为它强制覆盖了工作目录中的文件。
在这种特殊情况下，我们的Git数据库中的一个提交内，还留有该文件的V4版本，我们可以通过git reflog来找回它。但是若该文件还未提交，Git仍会覆盖它从而导致无法恢复。
