git分支冲突的场景分析和解决办法

前提描述： 分支B 往分支A 合并。即： A merge B 或者可以表述为： B to A .出现冲突

git 合并分支时冲突的解决方法

方法1： 在分支B 上 rebase origin/A，然后解决冲突
方法2： 在分支A 上 merge B ，然后解决冲突

方法3： 在分支B 上 merge A，然后解决冲突 （此方法就是为了留下合并记录的）

场景分析

1. A B 俩分支都是可以直接操作的，即：非受保护分支。B分支是从A 分支迁出的，B 分支是临时子分支，后续不再需要维护，则可以使用方法2
2. A B 俩分支都是可以直接操作的，即：非受保护分支。B分支是从A 分支迁出的，B 分支是临时子分支，但是后续跟进和持续维护，则可以使用方法1
3. A分支是受保护分支，B分支是从A 分支迁出的，B 分支是临时子分支。则可以使用方法1
4. A B 俩分支都是受保护分支，且各有不同，不需要保持完全一致。比如：A分支是master 生产环境的分支，B分支是Dev 测试环境的主分支，且这俩分支在环境的配置上面有一些不一样，即A分支和B分支有一些各自的不同的commit。而A B 分支都需要保留这些特殊点。那么此时 需要：

A checkout -b C
C merge B （解决冲突，并产生一条新merge 记录）
A merge C
A merge B（此处原有的冲突，是自动解决的）

可以理解为A 没法直接操作，so 迁出一个新分支C ，C代替A 做merge操作。C解决冲突后再合并到A 上。

小结：为什么（可以但）不建议使用方法3

个人认为：特性分支 rebase 主分支，或者 主分支merge 特性分支。是比较合理的办法。
merge 会生成一条commit记录，然后你解决冲突就是在此条记录里完成的。rebase解决冲突是在本身的commit里完成的。
因为特性分支其实不是很关心本次合并了主分支的哪些变动。只要主分支知道某次合并有哪些变动就行了，所以在主分支使用merge就行了。

语法解析：

• B rebase origin/A ：是将A目前已存在的所有commit拿过来当做B分支的基底，此次在B上提交的commit，会被放到最后。
  注意：rebase 解决冲突 是不会有提交记录的，是直接改动原有 commit。
• A merge B ： 是将B 分支上新提交的commit，拿过来放到A 的当前commit的后方。merge会产生一条新的commit记录【Merge branch ‘B’ into ‘A’】。
  注意：
  1. 如果有冲突：merge的这次提交 可以解决冲突，同时不会影响到原有的 提交记录，
  2. 如果没有冲突：可以记录本次merge是把哪些commit弄到A 上的，此时merger相当于做个汇总，并链接到了原有的commit 。（具体参考下方的案例分析）

案例分析

比如主分支master， 有m1, m2 ,m3的3个提交记录。

dev分支从master切出一个分支开发，然后开发了d1,d2 这2个功能。那这个时候dev分支的提交记录是m1,m2,m3,d1,d2。

此时master有一个新的提交，m4。m4 和 d1 有冲突，然后dev需要合并这个主分支。
如果再dev分支上用rebase，dev分支上的提交记录就会变成 m1,m2,m3,m4, d1,d2,d3

如果用再dev分支上用merge， dev分支上的提交记录就会变成 ：m1,m2,m3,m4,d1,d2, [ merge master to dev] (此commit：若有冲突，就是解决冲突用)，如下图所示

然后再master merge dev, master 上是：m1,m2,m3,m4,d1,d2, [ merge master to dev] (若有冲突，就是解决冲突用) ， [ merge dev to master] （记录合并的commit），如下图所示

在下图可以看出，代码里提示的是其真实的commit，并不会收到 merge commit的影响