问题描述：
在gitlab上面做合并操作，出现冲突，解决冲突后提交，确认合并，发现两个分支互相合并了，平白无故多了很多麻烦，巨坑。
已经被它坑了不少次了，如果使用 Gitlab 提供在在线冲突解决工具的话，本来是将 A 往 B 合并的，结果变成了 B 往 A 合并，导致分支管理混乱。这个设计合理吗？
git正常的合并分支：
切换到目标分支
执行合并命令，git merge 源分支
没有冲突合并结束，出现冲突，在目标分支上面解决冲突，执行commit命令，合并结束
然而，gitlab上面做合并分支的操作，出现冲突时，gitlab是在源分支上面提交我们解决冲突的代码，最后点合并的时候再把源分支合并到目标分支，这就导致合并结束后，源分支与目标分支出现互相合并的效果，产生很多没必要的问题。
后来才找到原因：
解决方法：
方法1：设A分支要合并到B分支，且出现了冲突，可以先从A分支拉一个临时分支a，用a分支合并到B分支
方法2：设A分支要合并到B分支，且出现了冲突，合并完成后，对A分支做回滚
git回滚版本：
git reset --mixed 目标版本号，回退一个版本,且会将暂存区的内容和本地已提交的内容全部恢复到未暂存的状态,不影响原来本地文件(未提交的也不受影响)
git reset --soft 目标版本号，回退一个版本,不清空暂存区,将已提交的内容恢复到暂存区,不影响原来本地的文件(未提交的也不受影响)
git reset --hard 目标版本号，回退一个版本,清空暂存区,将已提交的内容的版本恢复到本地,本地的文件也将被恢复的版本替换
回滚后再强推到远程git服务器：git push -f origin test 强制推送到远程分支，-f 强制，origin 远程仓库名，test 远程分支名
git revert 目标版本号
这个命令在本地反向做一个版本抵消目标版本，然后正常commit提交，push到远程分支
原文：https://blog.csdn.net/superyueguang/article/details/114309492