当我们项目发布上线发现有问题，又无法立马解决，需要版本回退的时候，应该如何处理，选择
revert还是reset。最怕版本回退有冲突，经历几次及测试以后，终于弄清楚他们之间的差别，下面就简单来说一下他们的使用方法及差别
reset
首先我们提交三次代码：
页面代码如下：
现在执行reset命令，把代码回退到4/7第2次提交之前的状态,命令如下：
git reset --hard HEAD^
- 执行命令以后，我们发现上一次修改的内容已经丢失，我们再通过命令
git log --oneline看一下提交的历史记录
我们看到，第3次提交的历史信息也被删除了，并且
HEAD当前处于我们要回退的版本，所以执行git reset命令，其实做了3步操作：
1:本地代码回退到指定的版本；
2:HEAD移到指定的版本；
3:移除回退版本之前的所有记录；按照理论，这个时候我们需要把本地的代码，再提交一次，然后发布，才可以达到版本回退的效果，命令如下：
git commit -a -m"reset以后提交"
git push
-
但是命令行却提示，有冲突，需要我们执行命令
git pull拉取一下代码,这样一步也说明了git reset命令重置的只是本地的代码，远程的代码并没有改变，按照说明，我们再次执行git pull
reset代码恢复 当我们拉取代码以后，线上的代码，又覆盖了我们本地的代码，这样下来，我们貌似无法达到线上代码回退的效果。那我们换一种方式，用强制推送到远程的方式去覆盖线上的代码试试,命令行如下：
git push -f
貌似公司有限制，禁止这样推送到远程，也就是用
reset达到线上的代码版本回退是很难的。为什么呢？因为reset命令，本质上只会重置本地的代码，并会自动重置线上的代码，
git reset命令还包括一系列参数，这些参数允许你使用最终提交的内容更新本地环境的其他部分。 这些选项包括：hard：重置repository中branch pointer的指向，使用commit的内容填充working directory ，以及重置staging area(暂存区域)。
soft：仅重置repository中branch pointer的指向。
mixed：（默认值）重置repository中branch pointer的指向。重置staging area(暂存区域)。
使用这些选项在目标环境中非常有用，例如git reset --hard <commit sha1 | reference>。 这会覆盖您尚未提交的任何本地更改。 实际上，它会重置（清除）staging area，并使用使用commit的内容填充working directory 。 在使用hard选项之前，请确保这是您真正想要做的事情，因为该命令会覆盖任何未提交的更改。
revert
同样我们先提交3个版本：
回退到上一个版本，命令行如下：
git revert HEAD
- 页面第3次提交的内容已经清除，同时命令行打开了
vim,这个时候，我们需要按下键盘的i键，进入编辑模式，输入提交说明如下：
- 说明输入完成以后，按下键盘的
Esc键，退出编辑模式，之后再按下:wq退出并保存编辑的内容如下所示：
- 当我们再次按下
Enter键的时候，我们就可以看到如下所示的提交信息
- 那本地的代码已经回退到指定的版本，那我们再用命令
git log --oneline看一下提交的记录：
我们看到之前提交的记录(revert提交3次)还存在，并且新增加了一个提交记录，就是我们刚刚输入的版本回退的记录，同时
HEAD指向了我们刚刚的提交版本，这就是说明，git revert做的操作是：在当前已有的版本的基础上，新生成一个提交，并不是把通过移动HEAD到之前的版本来达到回退的效果，这样可以保证我们所有提交的记录都是存在，不会丢失。然后我们就可以执行
git push命令，推送代码到远程服务器：
通过，亲自操作
git reset和git revert我们看到了它们两个的区别，git reset适合回退本地代码，比如，项目我们修改很多以后，发现想回到最开始的版本。而git revert适合，项目上线以后，发现有问题，需要版本回退，这个时候，可以基于之前的版本，再创建一个新的提交，重新发布就可以，而且之前提交的记录都存在，而git reset是重置的意思，当我们执行了这个命令以后，不但代码回退到指定的版本，之前的提交记录也是会给清除，所以git reset一定到慎重使用，因为它会造成不可回退的效果，除非我们知道之前的提交的哈希值才可以。
