在Github中申请PR,请求a合并到b,有时候没冲突,好办。有时候有冲突,这时候该怎么办?
下面的PR是feat_617合并到feat_w8y,可以看到 “Can’t automatically merge”,可以知道,本次PR不能自动合并,因为合并中出现了冲突。
不要点击 “Create pull request”,在本地处理好冲突后再提交PR。本地处理的方法一般就是用IDEA处理好后顺便还能观察是否编译、打包能通过。
详细怎么处理?,假设你想提PR将feat合到dev,方法有两个
在本地先将dev合到feat,解决好冲突后再提PR(有点绕,后面会解释)
在本地从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也有点绕,但其实你画下图就好理解了(详细参见后面)
继续点击创建pull request 绿色那按钮(不建议),创建好了之后页面会出现让你解决冲突的 Resolve conflicts
点击并解决冲突。之所以不太建议,是因为你在网页上操作,简单的还好,文件一多,依赖关系复杂,就会出现改错,还是老实到IDEA里处理好冲突之后再提PR吧。
进入处理冲突的页面,解决完毕后点击 Mark as resolved,然后会出现commit merge按钮,点击它,然后继续创建PR。
1、两分支合并,其实有3种情况
2、更详细的解释
最左的图是初始状态,dev分支在c3上,feat分支在c5上
需要注意的是无论是图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不动(右图),此时
3、至于为什么分支合并中a合b跟b合a结果是一样的,这个需要多点思考。应该来说本质都是将两者的差异柔和在一起吧。怎么说呢,就是对方比自己多的revsion整合到自己这边把?!