文章目录
改进后的GitFlow工作流
GitFlow工作流
如果多个版本频繁并行开发，此时完全参照 GitFlow 是不现实的。因为它会导致在 develop分支 里会混合多个版本的代码，同时在进行集成测试，如果一个版本先测试完，要先进入QA测试环节，是不可以直接基于 develop分支 去拉 release分支 的，因为 release分支 会混合多个版本的代码一块儿测试。
所以需要基于GitFlow工作流做一点改进。就有了如下图的改进的GitFlow工作流
整个依赖基准的分支只有一个，就是 master分支，全部以 master分支 为基准和基础，master也是最稳定的分支。
比如说启动一个版本 v1.0.0，涉及 3 个功能，投入了 3 个 RD：张三、李四、王五。他们直接从 master分支 拉 3 个 feature分支 下来，而不是向经典GitFlow工作流一样是以 develop分支 为基准拉取分支。
同时要做一个 v1.1.0 版本，涉及 5 个功能，投入了 3 个 RD：小A、小B、小C，他们也直接从 master分支 拉 3 个 feature 下来，每个人都要基于自己的 feature 去开发
除此之外每个版本刚开始启动时除了拉一堆 feature分支，还需要同时从 master分支 拉一个 develop分支 下来，专门用于这个版本的集成测试。比如 develop/v1.0.0分支 就只用于 v1.0.0 版本的集成测试， develop/v1.1.0 分支就只用于 v1.1.0 版本的测试。从而保证 QA 测试时一个版本就对应一个 develop分支 的代码，而不是将多个版本的代码混在同一个 develop 中进行测试。
一个 develop分支 完成后，QA 基于该版本拉一个 release分支 进行测试。
比如 张三、李四、王五 开发完后都将代码合到 develop/v1.0.0分支，且解决了途中可能出现的冲突等问题。此时 QA 就基于 develop/v1.0.0 版本 pull 一个 release/v1.0.0分支 进行集成测试。
如果是经典的GitFlow工作流，那么一旦小 A 组先测试完毕合到 develop分支，张三组后合到 develop分支，QA 从此时的 develop分支 拉取 release分支 做集成测试时，由于代码混有小 A 组的代码，就会导致一系列问题的出现。
改进式工作流的解决方法除了对每个版本独立一个 develop，每次测试都是基于独立的 develop分支 外，还引入了一个 staging分支。它也是基于 master，且是线上最新代码和 release分支 merge 后的结果。
QA 在对 release/v1.0.0分支 集成测试完后，由小组 leader 将它和 staging/v1.0.0 分支 merge。这里假定张三组回归测试完毕，先将代码推送到 master。此时如果小 A 组再 push 时，就需要先基于 staging/v1.0.0 分支 pull 一个 staging/v1.1.0分支 ，然后和 release/v1.1.0 分支 merge，没问题后再将此时的 staging分支 合并到 master 上。
由于有可能别的代码已经合并到 master 上了，所以在 merge 时可能会有很多冲突，需要不断的对 staging 进行冲突解决，回归测试等。同时，由于 staging 代码会把集成在一起的多个版本的代码合并在一起，所以对 staging 版本进行回归测试时，要保证对应的功能全部进行了回归测试，确保每个版本的代码对应的功能都正常运行。一旦确定没问题后，就可以将 staging 分支 和 master分支 进行 merge 了。
merge 完后对最新的 master 代码进行验收。验收完毕后打 tag 上线。重复上述步骤。
总结
- 基准代码只有 master
- feature 和 develop 都从 master 拉取，以 master 为准
- 每个版本的RD各自迭代，各自独立开发，独立测试，加速开发和测试的进度
- release 分支跟 master 分支的代码，以 staging 分支为基础进行合并，实现多个版本之间的代码集成
- staging 代码和 master 分支合并在一起，打 tag，准备上线，这个版本就实现了上线
工作流总结
（1）微型项目，集中式工作流
（2）小型项目，功能分支工作流
（3）中小型或中大型项目，由于维护和版本迭代缓慢，GitFlow工作流
（4） 快速发展的业务和项目，改进式GitFlow工作流