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、想问问大家是怎么处理开发合并了冲突代码这种情况
还有一个问题想请教一下，合并代码的时候是用 rebase 还是 merge 呢？
我平时维护自动化框架时，是先在 dev 分支上 rebase master，然后再切换到 master，把 dev 分支 merge 过来。
用 rebase 的话，整个提交就是一条记录，不会出现各种分叉，强迫症患者的福音。但是有个坏处就是会改变原本 git 提交的记录，不过代码还是一样的。
定版发车，单拉分支，版本 +1，发车日期过了，自动顺延，不怕插入新需求
没有 develop 分支吗
gitflow 工作流程，了解下
版本控制流程你们需要重新梳理好。A，E 代码会冲突，说明是同一个功能，E 应该是修复一个紧急 bug，这种仅测试功能 + 自动化跑主流程，A 再正常测试就好了，同一个迭代周期发多个版本，就会出现这样的问题。归根到底还是流程问题，要么固定版本，要么合并需求，否则只能重复测试。
等于说代码合并还要测试去操心了，左移的有点远了吧。
改进流程才是正确的。我们之前版本也是这样 说上就要上版本频发，开发也难受，测试也经常加班，再怎么测试还是多多少少会出现一些问题，老板总以为测试不到位。目前我们改进就是学习 gitflow 工作流程，并且控制版本 一周一个小迭代，一个月一个大迭代。
A，E 代码会冲突，说明是同一个功能的不同的改动，如果 E 先合并 master 了（尤其是已经上线了），再回来测 A 时，需要先把 master 再合到 A 分支，测试 diff 的时候，检查一下是否有奇怪的删除行。。我一般就是这么做的。如果是要同时上线，那我觉得你们这种只有一个 master，没有 dev 分支的开发测试流程，可能是有问题的。。。。这是我个人的愚见
萧胤祥
回复
可能是我个人操心的有点多，我平时还会 review 开发的代码，并且有问题会启动远程调试。
因为我这个测试是没有界面的，从代码层面去测试才能够更加深入理解业务
黎睿渊
回复
只有一个 master，需求就起一个 feature 分支，按照楼上各位童鞋推荐的 gitflow，至少应该还要有一个 develop 分支才行
