Github或Gitlab等申请PR或MR（pull request & merge request）的或G或时候如果不能自动合并代码发生冲突了要怎么办

背景

在Github中申请PR，请求a合并到b，等t的动合有时候没冲突，申请时候生冲好办。并代有时候有冲突，突办这时候该怎么办？

实验

下面的或G或PR是feat_617合并到feat_w8y，可以看到 “Can’t automatically merge”，等t的动合可以知道，申请时候生冲本次PR不能自动合并，并代因为合并中出现了冲突。突办

解决办法：

方法1：

不要点击 “Create pull request”，或G或在本地处理好冲突后再提交PR。等t的动合本地处理的申请时候生冲方法一般就是用IDEA处理好后顺便还能观察是否编译、打包能通过。并代

详细怎么处理？，突办假设你想提PR将feat合到dev，方法有两个

1. 在本地先将dev合到feat，解决好冲突后再提PR（有点绕，后面会解释）

2. 在本地从dev拉出临时分支dev_tmp，然后将feat合并到dev_tmp，解决完冲突后

​ 2.1 提PR请求 dev_tmp合并到dev（好理解）

​ 2.2 或将dev_tmp合并到feat，然后提PR请求feat合并到dev（稍微有点绕，不过此时dev_tmp合并到feat一定是fast forward的）

第一种方法是有点绕，其实你只要只要a合并b和b合并a是一样的就行了。2.2也有点绕，但其实你画下图就好理解了（详细参见后面）

方法2：

继续点击创建pull request 绿色那按钮（不建议），创建好了之后页面会出现让你解决冲突的 Resolve conflicts

点击并解决冲突。之所以不太建议，是因为你在网页上操作，简单的还好，文件一多，依赖关系复杂，就会出现改错，还是老实到IDEA里处理好冲突之后再提PR吧。

进入处理冲突的页面，解决完毕后点击 Mark as resolved，然后会出现commit merge按钮，点击它，然后继续创建PR。

思考

1、两分支合并，其实有3种情况

• fast-forward：这种是某个分支落后于另外一个分支，且只要移动这个分支的HEAD指针到另外一个分支所在revision即可
• 虽然不是fast forward，但合并过程自动进行没有冲突。通常见于各改各的
• 合并出现冲突，通常是不同分支对同一行编辑

2、更详细的解释

最左的图是初始状态，dev分支在c3上，feat分支在c5上

• 当feat合并到dev的时候，由于不是fast-forward，产生新的revision来承载双方，即c6。（中间的图）
• 当dev合并到feat的时候，反过来。（右边的图）

需要注意的是无论是图2还是图3，合并的结果是一样的

上面的图中，中间的图执行feat合并到dev，或者右边的图执行dev合并到feat，都会得到如下的结果，即dev和feat都指向c6

所以你可以想象，就算是多出一个dev_tmp，结果是一样的，大概是如下

最初dev在c3，feat在c5，从dev拉出dev_tmp肯定也在c3（左图），此时feat合并到dev_tmp，dev_tmp前进到c6二dev和feat不动（右图），此时

• 无论是申请dev_tmp合并到dev（导致dev发生fast-forward到c6）
• 或者是先将dev_tmp合并到feat（导致feat也发生fast-forward到c6），此时再审批PR让feat合并到dev其实跟申请 dev_tmp合并到dev是一样的结果，最终都是导致dev到达c6

3、至于为什么分支合并中a合b跟b合a结果是一样的，这个需要多点思考。应该来说本质都是将两者的差异柔和在一起吧。怎么说呢，就是对方比自己多的revsion整合到自己这边把？！