关于git flow工作流程的一点思考
具体流程暂不细表，参考文章中已经极为详细。
Git Flow工作流程
- 开发阶段：从develop分支拉出feature分支进行开发
- 联调阶段：直接使用feature分支进行联调
- 提测阶段：将feature分支合并入develop分支，并基于develop分支拉出release分支进行提测
- 发布阶段：将release分支分别合入master分支以及develop分支，并打上版本号
碰到的问题
倘若存在2个feature分支[feature1.0/feature.2.0]
feature1.0已经合并入develop分支并拉出release分支进行提测bug修复
过了不久，feature2.0开发完毕，合并入develop分支并拉出release分支进行提测
如果第二个分支先于第一个分支发布，master就合并进了还没修复完的feature1.0的代码
解惑
通过第一文章作者留下的联系方式加了他的微信，这是他回复给我的:
这种工作方式：一般情况要遵循feature1.0分支先于feature2.0发布。
也就是：只要先合并到develop就说明已经具备先发的条件。
同时在第二篇文章阮老师留言下面发现了同样类似的回答：
git-flow-1.png
git-flow-1.png
[第二个回答也是我们小团队目前正在使用的方式]
感谢前人。
公司目前使用的流程
- 开发阶段：从master分支拉出feature分支进行开发
- 联调阶段：直接使用feature分支进行联调
- 提测阶段：从master分支拉出一个release分支，使用该release合并feature分支，然后进行提测
- 发布阶段：提测结束后，将release分支合并入master分支，进行发布，也可直接发布release分支再合并入master分支，并打上版本号
好处
需求发布无需严格遵循需求先后发布时间，不存在标准git flow工作流程碰到的问题
缺陷
在标准工作流中
master分支用来记录官方发布轨迹；develop分支是一个集成分支，用来记录开发新功能的轨迹。
而在实际开发过程中由于没有使用develop分支，master分支commit较为混乱，使用标准工作流又会碰到发布冲突的问题
- 总结
来自第一篇文章作者(再次表达感谢)：
不管用什么方式，能保证工作顺利进行就行。
每个项目工程的复杂度都不一样，要从实践中找到适合团队协作的方式。
还就是，有些约定，是必须遵循的。
后话
最近写博客越发觉得自己只是知识的复述者，复述得还没有别人好，开始怀疑自己花时间投入写博客是否值得。
自己还处于学习阶段，也没有原创输出。
倘若不写，又感觉自己学习的知识印象不深，写还是要写的，权当学习记录了。
当然，倘若能够帮助到一些人，我会更开心。
如果文中有表述不当的地方还望指出。互相学习共同进步。
