git reset  --hard：彻底回退到某个版本，本地的源码也会变为上一个版本的内容，此命令 慎用！

git reset 命令是git中最常用的命令，但也是最危险，最容易被误用的命令。

    我们知道git在初始化时，会为我们默认创建一个master分支，那这个master到底是什么呢？其实它在.git目录下对应了一个引用文件-----.git/refs/heads/master文件，而该文件的内容便是该分支中最新的一次提交的ID：

   当我们用以上查看master文件内容时，发现它果然记录了最新一次的提交。了解了这个前提，那我们来分析下git reset到底做了什么？

    以上面的例子为基础我们来探讨reset命令的魔力，首先我们来执行一个reset命令，reset到上一次提交

   HEAD^的意思就是最新一次提交的父提交，reset后，我们看一下提交日志，发现最新一次提交没了。到底git做了什么呢？我们还能找回最新的一次提交吗？

    回答上面两个问题，就用到上面就到的master引用文件了，这是我们再看一下这个文件的内容有什么变化？

   发现了吧，里面记录了reset后的最后一次提交。这时或许我们有所觉察了。先不急着下结论，我们看怎么回到最新的提交呢？其实reset后，git没有删除最新提交的相关信息，包括目录树，因此只要我们记住提交ID，便可以重新reset回来：

   这样查看log，发现最新提交又回来了。但是如果我们忘了最新提交ID 怎么办呢？好办，reflog命令可以最总引用变更的记录：

   我们可以找到前面任意操作的记录，并且可以reset到任意提交。

    之前我们看到了reset后master文件的内容发生了变化，其实这就是reset命令的本质，但结合不同的参数，会有额外的工作：如--hard --soft --mixed等，他们决定了是否重置暂存区或工作区。

我们来看下面图片

其实reset命令有两种用法：

git reset [-q] [commit] [--]

git reset [--soft | --mixed | --hard | --merge | --keep] [-q] []

第一种用法是不会重置引用的，即不会修改master文件。只是用某一次提交的文件提交暂存区的文件

第二种用法不使用 则会重置引用，并且参数不同决定是否覆盖暂存区和工作区：

--hard参数会执行途中1,2,3 全部动作，即暂存区，工作区全部用指定提交版本的目录树替换掉

--soft 参数只执行1， 不进行暂存区和工作区的覆盖

--mixed或不使用参数，执行1,2覆盖暂存区，但不覆盖工作区

这样一来相信对reset的理解会用更深刻的理解了吧。