对两者之间的区别，写的太罗嗦了，后来自己练练手，练得多了，才有了自己的感觉，reset好比是物理学中的“位移”那样的感官，提交到哪个点，位移就是开始到现在这个点的距离，超过这个点走的路程被隐藏了不显示。
revert呢？打个比方吧，一个人每天都有一个生活记录，形成镜像，每个镜像从时间角度看就是依次联系逐渐成长的过程，但是每个镜像也是独立存在的，从一个镜像里可以看到从出生到镜像现在的变化。
revert就是单独作用在某个镜像，这个镜像不变，但是作用之后，产生了一个新的镜像，只不过可能会产生冲突，冲突只是因为为了产生新镜像，违背了其他镜像的逻辑性，但是跟其他镜像的关系也是独立存在的，不会去改变其他镜像的，这个新的镜像是我的目的。具体下面来练练手吧。
</p>
reset
如果改项目出了什么乱七八糟的错误，想回到以前觉得还不错的版本里，这里出现了不同的用户需求了，只要reset了，HEAD肯定会变到当时版本了，这个是为了让远程库得到这个版本的需求的。同时，暂存区可以同步改变，也可以保持现状，这个看个人需求了。同时，原文件也会相应地变或者不变的。
git reset --hard HEAD~
这个就是最简单粗暴的急救命令了，比如一个人从小孩到最光彩的中年再到老年死去，这命令可以让这个人直接回到最光彩的中年，场景一模一样，可以再活一次，当然老年的所有痕迹也都不会存在了。
我想回到3那次改动后的场景，包括暂存区和原文件都穿越了
这里运行status命令说明文件和暂存区一致的，运行log命令，如图，记录也仅仅到了当前3的，没有了4,5。
</p>
git reset --soft HEAD~
这个命令就有趣了，这里的暂存区和文件是不变的。仅仅是对远程库的表现回到从前版本，感觉好像大牛开发项目远超其他伙伴，不得不把低版本的表现出来配合进度。
我先用上一个命令回到5的提交状态。
提示暂存区与本地库不一致了，用
git reset HEAD
还是5的状态，没变的。
得到提示，本地库已经落后于远程端了，需要用pull。
由此说明这里只有HEAD变了，暂存区和原文件没变。
revert
特定取消某个版本的提交，其他版本不管，只针对面上的一个点，所以没有路程或者位移的感觉了，并且提交后会产生新的commit被记录，好比，所有的项目都做差不多了，就是两天前的一个小文件有问题，如果要用到上面的reset的话，这两天就白干了。
我再用reflog查询命令记录，回到5的状态，开始编辑3次，把1,2,3,按顺序删除。用log得commit界面
我想把2留下来，就是想撤消shan2这个提交。
报错了，什么意思呢？这里你撤消shanchu2的提交，但是下面的shan3没有变，所以起了冲突了，打开文件
HEAD当前结果为54，shan2的结果为5432，这里因为冲突很小，手动修改不麻烦，直接手动编辑，删除不想要的，得到想要的542，保存退出，然后
再vim打开
就是想要的结果啦。
如果手动编辑很麻烦的话呢？另一种做法：报错之后，先强制结束revert,默认 不 生成新的commit，并按顺序回滚。先log一下，查看commit
我这次要撤消shan3的提交，也就是543。
命令图如下
其中obort是强制中断命令，--no-commit参数就是不提交的意思，最后
git revert --continue
会自动跳出编辑框，填写提交注释的。
</p>
大体简单到这里，还有一些，比如reset命令撤消暂存区文件，可以使提交的文件具有选择性等等吧，大家可以一起研究下。现在感觉reset最好适合本地库谨慎使用的，不可随意使用提交之后推到远程库，容易让其他人看你远程库的时候云里雾里，revert倒是很实用，虽然撤消了提交，但是历史记录还在，新生成的提交的逻辑，外人很容易明白的。
思考
对于revert的两个运行例子，想了想结果其实挺怪的，第一个结果无所谓，我手改的结果如何，都符合revert的定义。第二个例子是在第一个例子作为HEAD的前提下开始的，结果呢，好像跟这个HEAD没关系，结果是543而不是5432，所以我突然想到了其中的逻辑， 只要运行revert得到的commit更像是在大树主干上分出的相互独立的枝杈，这些枝杈在逻辑上直接跟撤销commit时的主干有关联，互相之间没有关联，仅仅是在log图表上有个时间上的先后结果罢了，而“顺序回滚”是借助log图表完成的，而到了目标commit那里，需要执行revert的行为遵循的则是log而不是主干。所以，如果想通过revert得到不仅撤消了commit之后的文件，还要使文件继续遵循下面的commit变化得出的更新结果，好像只能用手动修改的方法了，顺序回滚得到的结果跟运用reset得到的结果差不多，只是有了每次操作提交的历史记录这个优点罢了。
