请直接看原文: 

【git revert】使用以及理解（详解）_git revert用法-CSDN博客 

-------------------------------------------------------------------------------------------------------------------------------- 

前言

试验得知:用Reset HEAD方式只能回退自己分支,并且是此次commit之后的全部回退,不满足回退某次提交的要求.

git revert

1.什么是git revert

git revert 撤销 某次操作，此次操作之前和之后的commit和history都会保留，并且把这次撤销，作为一次最新的提交。

git revert HEAD 撤销前一次 commit
git revert HEAD^ 撤销前前一次 commit
git revert commit （比如：fa042ce57ebbe5bb9c8db709f719cec2c58ee7ff）撤销指定的版本，撤销也会作为一次提交进行保存。

git revert是提交一个新的版本，将需要revert的版本的内容再反向修改回去，
版本会递增，不影响之前提交的内容

2.git revert 和 git reset的区别：

git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。

1、在回滚这一操作上看，效果差不多。但是在日后继续merge以前的老版本时有区别。因为git revert是用一次逆向的commit“中和”之前的提交，因此日后合并老的branch时，导致这部分改变不会再次出现，但是git reset是之间把某些commit在某个branch上删除，因而和老的branch再次merge时，这些被回滚的commit应该还会被引入。

2、git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。

3.revert理解

当讨论 revert 时，需要分两种情况，因为 commit 分为两种：一种是常规的 commit，也就是使用 git commit 提交的 commit；另一种是 merge commit，在使用 git merge 合并两个分支之后，你将会得到一个新的 merge commit

merge commit 和普通 commit 的不同之处在于 merge commit 包含两个 parent commit，代表该 merge commit 是从哪两个 commit 合并过来的。

在上图所示的红框中有一个 merge commit，使用 git show 命令可以查看 commit 的详细信息

➜  git show bd86846
commit bd868465569400a6b9408050643e5949e8f2b8f5
Merge: ba25a9d 1c7036f

这代表该 merge commit 是从 ba25a9d 和 1c7036f 两个 commit 合并过来的。

而常规的 commit 则没有 Merge 行

➜  git show 3e853bd
commit 3e853bdcb2d8ce45be87d4f902c0ff6ad00f240a 

4.revert的三种使用场景

revert 常规 commit

使用 git revert <commit id> 即可，git 会生成一个新的 commit，将指定的 commit 内容抵消掉。

 revert merge commit

revert merge commit 有一些不同，这时需要添加 -m 选项以代表这次 revert 的是一个 merge commit

但如果直接使用 git revert <commit id>，git 也不知道到底要撤除哪一条分支上的内容，这时需要指定一个 parent number 标识出"主线"，主线的内容将会保留，而另一条分支的内容将被 revert。

如上面的例子中，从 git show 命令的结果中可以看到，merge commit 的 parent 分别为 ba25a9d 和 1c7036f，其中 ba25a9d 代表 master 分支（从图中可以看出），1c7036f 代表 will-be-revert 分支。需要注意的是 -m 选项接收的参数是一个数字，数字取值为 1 和 2，也就是 Merge 行里面列出来的第一个还是第二个。

保留主分支，应该设置主分支为主线，操作如下：

➜ git revert -m 1 bd86846

 revert 之后重新上线

下面是我复制过来的,试验得知,不用那么麻烦,第四步直接再 merge 到 master 即可,git很智能的,会自己处理好.

第一步:

假设tom在自己分支 tom/feature 上开发了一个功能，并合并到了 master 上，之后 master 上又提交了一个修改 h，这时提交历史如下：

a -> b -> c -> f -- g -> h (master)\      /d -> e   (tom/feature)

第二步: 

突然，大家发现tom的分支存在严重的 bug，需要 revert 掉，于是大家把 g 这个 merge commit revert 掉了，记为 G，如下：

a -> b -> c -> f -- g -> h -> G (master)\      /d -> e   (tom/feature)

第三步:  

然后tom回到自己的分支进行 bugfix，修好之后想重新合并到 master，直觉上只需要再 merge 到 master 即可，像这样：

a -> b -> c -> f -- g -> h -> G -> i (master)\      /               /d -> e -> j -> k ----    (tom/feature)

第四步:  

i 是新的 merge commit。但需要注意的是，这 不能 得到我们期望的结果。因为 d 和 e 两个提交曾经被丢弃过，如此合并到 master 的代码，并不会重新包含 d 和 e 两个提交的内容，相当于只有 goudan/a-cool-feature 上的新 commit 被合并了进来，而 goudan/a-cool-feature 分支之前的内容，依然是被 revert 掉了。

所以，如果想恢复整个 tom/feature 所做的修改，应该先把 G revert 掉：

a -> b -> c -> f -- g -> h -> G -> G' -> i (master)\      /                     /d -> e -> j -> k ----------    (tom/feature)

其中 G’ 是对 G 的 revert 操作生成的 commit，把之前撤销合并时丢弃的代码恢复了回来，然后再把tom的分支merge到master分支上，把解决 bug 写的新代码合并到 master 分支。