工作流

介绍一下我接触到的常用的2种git工作流： 1是master=>feature=>develop=>master 2是master=>feature=>develop，然后feature=>master

下面来分别介绍一下：

1、根据版本更新：master=>feature=>develop=>pre-master=>master

场景：项目这次迭代中，包含A、B 2个需求，并且经过评估，在上线时间前，开发测试完成是没有风险的，开发完成后，按照迭代部署时间，这次版本（A、B功能）上线。

操作流程：

• 从master分出develop，然后从develop分出feature_newPage1和feature_newPage2，分别进行开发
• feature_newPage1修改了common方法，合并到develop，通知feature_newPage2的人员pull一下develop
• 开发结束，自测通过后，合并到develop，测试人员进行测试
• 如果有bug，就直接在develop上修改，然后再部署测试
• develop测试没有问题，再合并到pre-master测试一遍，如果有bug就再切回develop修改
• 最后pre-master测试没有问题，合并到master

优点：

• 对于feature1和feature2有公共部分的这么开发，流程清晰，feature1和feature2的开发人员通过沟通，可以迅速同步公共代码 缺点：
• 不能根据模块发布版本

总结： 当一次迭代周期内的开发需求，需要修改的公共部分较多，并且开发风险小（按时开发完成）时，可以使用这种流程， 这里的develop分支其实更像版本的意思，叫做sprint1、2、3...分支可能更加贴切，最终向master合并的是版本维度而不是模块维度

2、根据功能模块更新：master=>feature=>develop=>pre-master，然后feature=>master

场景：我接到2个需求A和B，开发完成后，产品经理通知，下次更新生产版本，只上A功能，B功能下下次更新再上

操作流程：

• 根据需求，从master分出feature_newPage1和feature_newPage2，分别进行开发
• 开发结束，自测通过后，合并到develop，测试人员进行测试
• 如果有bug，切换回feature，进行修改，然后重复上一步操作（合并到develop）
• develop测试没有问题，再合并到pre-master测试一遍
• 最后把feature合并到master，完成开发

我们注意到，在这个流程中，develop、pre-master、master是不互通的，所以在平时要每隔一段时间，就同步一下develop、pre-master、master三个分支，可能会发生一些冲突，这个要人为处理

优点：

• 可以根据功能模块更新版本 缺点：
• 需要定期同步develop、pre-master、master
• 如果各个feature有公共的模块，比如feature2有个功能要依赖feature1的功能，或者，feature1和feature2都使用了common1方法，同时feature1还对common1进行了很大的修改！ 这样的话可能需要把修改common1的工作单独拉出一个feature_common1的分支，并且要优先开发这个功能，这个比较麻烦

总结： 当开发多个相对来说比较独立的功能，其中某些功能有开发风险，各功能可能不同时上线的时候，可以采取这种git开发流程

最后

本文列举了工作中用到的2种方法，有啥建议和不足欢迎讨论和指出！