昨天说到用git reset进行回滚操作，还有git revert的操作，它们的区别如下:
git reset
git reset的作用是还原Index的状态或修改本地分支HEAD的位置。这个命令适合用于从某个提交点开始，重新开新的分支。比如，如果某个提交之后的代码我们都不要了，就可以在本地reset至指定commit，然后开一个新的branch继续新的开发（原来分支在远程上没有发生任何变化的）。
使用git reset是不影响远程分支的，一切都在本地发生。如果回退需要很快影响远程分支的，应该使用git revert。
两种情况
第一种情况：只是在本地commit，还没有push到远程分支，可通过以下命令实现:
git reset --soft|--mixed|--hard <commit_id>
git push 本地分支名称 远程分支名称 --force这里的<commit_id>就是每次commit的SHA-1，可以在git log里查看到
--mixed: 只是将git commit和index 信息回退到某个commit版本，仍会保留该commit_id之后提交的代码
--soft: 只回退到commit信息到某个版本,不涉及index的回退,会保留源码,如果还需要提交, 直接commit即可.
--hard: 源码会回退到某个版本,commit和index 都会回退到某个版本. (这种方式会改变本地代码仓库源码)
当然有人在push代码以后,也使用 reset --hard <commit_id> 回退代码到某个版本之前,但是这样会有一个问题, 线上的代码仍是回退之前的，线上commit, index都没有变, 当你把本地代码修改完提交的时候你会发现全是冲突.....
git revert
假如某些旧提交我们不想要了，而又不愿通过 自己修改这些旧提交所产生的代码，然后重新提交的方式 来完成，这个时候我们就可以把这项工作交给revert命令。
Git Revert原理：根据你要回退的提交所做的改动做方向相反的改动，然后重新提交代码，使代码达到没有这些旧提交所能达到的状态。
如果对于git revert的回退策略还没理解，这样讲也许你就能理解了：回退旧的提交必然会导致当前最新代码发生变化，比如之前某个提交加了一行代码，那么回退就是在相同位置减一行代码。Git不会真的把旧提交抛弃，如果直接抛弃，历史记录就追踪不到了。因此，旧提交其实是没动的，Git只是根据旧提交反着做了一遍，这才导致最新的代码发生了改变。只有把revert命令回退导致的改动重新提交，revert命令才算真的完成并生效，否则效果只相当于修改了工作树的文件而已。注意：revert之后需要push到远程分支上其他用户才能看到回退发生的改动。
使用git revert会出现的问题
因为git revert是用新提交覆盖旧提交，因此，被覆盖的旧提交等于不会被采用了。如果两个分支（假设是master和A分支）先合并再用revert回滚，之后又合并（A合并到master），就会发现在master分支上，A分支第一次合并之前的修改大部分不见了。这是因为从时间的发生顺序来看，A分支第一次合并之前的修改发生在revert之前，revert发生在后，而 revert抛弃了A第一合并之前的修改，那么再此合并Git就认为你永远抛弃了A第一次之前的修改。
要解决这个问题，需要把revert产生的提交再revert一次(相当于恢复之前的旧提交)。
两者区别
注意：git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit，看似达到的效果是一样的，其实完全不同。
第一：如果已经push到线上代码库, reset删除指定commit以后, 你git push可能导致一大堆冲突，但是revert 不会；
第二：如果在日后现有分支和历史分支需要合并的时候, reset 恢复部分的代码依然会出现在历史分支里，但revert 方向提交的commit 并不会出现在历史分支里(注意!!!)；
第三: reset 是在正常的commit历史中, 删除了指定的commit, 这时 HEAD 是向后移动了, 而 revert 是在正常的commit历史中再commit一次, 只不过是反向提交, 他的 HEAD 是一直向前的。