事情起因，本来我们系统需求已经测试通过，开发人员准备上线，于是便把release的代码合并到了master打包。快要上线时，突然依赖方告知有些功能未实现，今晚上不了了，上线日期待定！开开心心的把代码合并到了master如今却要回退。
这个简单，gitlab上对本次提交的request记录上有个revert按钮，只需要点击它便可以生成一次回退的commit。你也可以使用命令revert。 R: --->A--->B--->C
M: --->A--->B--->C--->D
--->A--->B--->C--->D--->E
当我们把R分支合并到M分支时会生成一个 merge commit D
D节点是我们需要还原的，我们对D节点进行revert生成的一次commit 为E的节点
当我们再想把R分支上被回退的功能代码合并到M分支上时，我们会发现提交一个mr时，代码没有做任何改动，也就说通过mr是无法重新找回已经回退的代码的。
我们从master上重新切出一个A分支
M: --->A--->B--->C--->D--->E
A: --->A--->B--->C--->D--->E
我们对A分支的E节点进行反做revert生成一个F commit.
A: --->A--->B--->C--->D--->E--->F 那么C节点的代码被还原了回来，也就说revert the previous revert，在把A合并到M分支即可。
所以总结下来分支的过程可以抽象如下图：
error: commit d2e4217b332e8bf1 is a merge but no -m option was given. fatal: revert failed
这个时候我们需要加 -m参数
git revert [id] -m [1|2]
通常您无法恢复合并，因为您不知道合并的哪一侧应该被视为主线。 此选项指定主线的父级编号（从 1 开始），并允许 revert 反转相对于指定父级的更改。
恢复合并提交声明您永远不希望合并带来的树更改。 因此，以后的合并只会带来由不是先前恢复的合并的祖先的提交引入的树更改。 这可能是也可能不是您想要的。