前言

今天来聊一聊gitlab的一个大坑，在线解决冲突之反向合并？除了分享的方式，大家也可以说一说其他的方式，或者自己的理解哦～

背景

在公司已经实习一段时间了，今天终于能腾出时间来写点东西了，想了许久，知识点太多太杂，就说说工作实际碰到的问题吧，让大家提前能看到这个问题，提早预防！我们组git代码有一套自己的规范，如命名该怎么做，遇到冲突该怎么做，都有文档提前规范好了，也是避免了这个大坑，但是我自己也是看到网上有说这个问题，但是也没有特别去关注这个事情，因为公司的规范已经解决了这个问题。

但是，谁知道恰好恰好，我的同事需求写完，在gitlab（当然不是gitlab，是内部一个基于gitlab的代码工具平台）合并代码，碰到了冲突，他也是选择通过在线解决去干掉冲突，干完他就懵逼了，gitlab直接给他自己的分支干进去了一堆提交，直接把测试环境的分支给干到了自己的分支？

这样会带来什么问题？？有人会说了，反正都是自己提交，合了也没啥问题，如果纯个人开发是没啥问题，但是对于实际业务来说，一个需求，可能也很多个人一起开发，也就意味着，你的目标分支下，不仅仅有你写的代码，同时还会有你的同事的代码，一下子，你直接把别人的需求干到本地了，首先肯定就不符合规范，其次，一旦你的同事有提交，都会影响到你提交，一干一个冲突（版本落后），问你心态崩不崩，严重影响开发。

解决方案

分支替代法

思路：我们主要的目的是解决当前分支与目标分支的冲突，因为有反向合并的这个问题，所以我们要如何不影响自己的分支，然后去操作干掉这个冲突呢？没错，我们可以使用一个临时分支，在当前自己的分支下，在本地切换一个新的分支，然后去merge目标分支，解决冲突后，提交代码，先将临时分支合并目标分支后，再回到自己的主分支进行开发，下次再用主分支去合并代码的时候，就不会有这次的冲突了。（我们组采用的方案也是这个）

#切换到自己的分支
git checkout 你的分支

#在本地切换并且创建一个新的临时分支
git checkout -b 一个新的分支

#合并远程仓库的目标分支
git merge origin/目标分支

#通过本地编辑器把冲突干掉后
git add . 
git commit -b ‘...’

#此时会提醒你远程没有这个分支，按照提示即可
git push

#提示应该是这样
git push --set-upstream origin 分支名

上述操作之后，然后将临时分支合并到目标冲突即可！之后你便可以回到自己的分支，照常进行开发了。

回滚法

因为我们小组遇到冲突，采用的就是分支法，平时我也没有用到过回滚法，但是我觉得还是有介绍的必要

具体过程就是：将你的分支和目标分支进行合并，并且在线解决冲突之后，因为会双向合并，此时你的分支已经受到污染，于是我们可以对自己的分支进行回滚操作！

git log //找到上一次的commitId
git reset --hard HEAD/commitID  //强制回退本地分支到上一个版本
git push origin HEAD --force 或者 git push -f origin feature //强制回退远程

最后

分支替代法是我在工作当中，也是公司文档规定使用的解决冲突的方法，并且文档声明是不允许线上解决冲突的

回滚法，网上有这个教程，我们也将这个方法放在这里供大家学习。

上述不知道哪里有说的不对的地方欢迎大家指正！！

大家如果有其他的思路，方法，欢迎在评论区进行留言讨论哦～