1、目前遇到的情况：

• 由于测试资源不足，导致提测多个需求积压，比如有 A，B，C，D 四个每个需求，都是基于 master 新建对应的 A，B，C，D 分支
• 中途可能会插入一个紧急的 E，F 需求，并且优先上线的，这样 master 就会往前推了，并且可能和 ABCD 分支修改了同一个地方的代码
• E，F 需求上线之后，也就是 E，F 分支合并到了 master。
• 现在 A 也测试完成了，测试时是在 A 分支构建测试的，测试通过后，目前做法把 A 分支合并到 master，假设 A 分支和 F 分支修改了同一个地方的代码，就会产生冲突。

2、手工解决冲突带来了不确定性

• 因为合并冲突了，导致 git 无法自动合并，需要开发手工合并代码，这时开发就要选择 A 分支或者 F 分支的修改了，如果迭代时间比较长，并且冲突多，很容易出现合并错误。
• 那么为了保证质量，把合并了 A 分支的 master 分支重新构建，再测试一遍，这相当于重新测试了一遍，很浪费时间。
• 目前我能想到的方法就是不要把 A 分支合并到 master，而是把 master 先合并到 A 分支。这样的好处就是就算合并出现错了，影响的只有 A 分支，master 不会向前推进提交记录。但始终还是会存在合并不全的风险

3、想问问大家是怎么处理开发合并了冲突代码这种情况