这里根据项目的进度和项目的人员规划，设计了几个不同的方案。仅供参考。
文章目录
- 背景
- 一、基本流程（最低要求版）
- 二、简易流程（过渡版）
- 三、最终流程（期望版）
背景
背景：随着业务以及需求迭代比较多。针对一个服务，可能需要多人之间协作开发完成。多人协作开发过程中，如果命名不做统一规范，或者分支使用不做统一规范，在后续测试，打版本，发生产过程中会造成混乱，可能会出现A同事合并B同事代码，C同事上线D同事为验证代码，E同事线上功能出bug想修复但是此时master已有合并提交代码，不知回滚哪一个版本等等问题。基于此，需要团队基于统一套标准使用GIT代码管理方式，尽可能避免以上问题。
一、基本流程（最低要求版）
如图说明：
新项目启动：master分支 -》 本地联调通过 -》 qa测试通过 -》 stage测试通过 -》 master直接发生产
第二次迭代开始：
1.从master分支拉一个本地分支，命名 feature/xxx/functionA（feature/git账户/功能说明）
2.本地分支开发完，发测试联调
3.qa验证通过，合并master，打tag
4.tag发stage，验证过，发pro二、简易流程（过渡版）
如图说明：
新项目启动：master分支 -》 本地联调通过 -》 qa测试通过 -》 stage测试通过 -》 master直接发生产
第二次迭代开始：
1.从master分支拉一个本地分支，命名 feature/xxx/functionA（feature/git账户/功能说明）
2.本地分支开发完，发测试联调（可以发feature/xxx/functionA到测试环境，也可以合并到dev分支发测试环境，推荐合并到dev发测试）
3.qa验证通过
4.从master重新拉一个release分支，命名release/2022-02-23.001 分支
5.把feature分支合并到release分支，在stage环境验证
6.stage验证通过后，release/2022-02-23.001分支打tag
7.tag版本直接发pro环境三、最终流程（期望版）
如图说明：
新项目启动：master分支 -》 本地联调通过 -》 qa测试通过 -》 stage测试通过 -》 master直接发生产
第二次迭代开始：
1.从master分支拉一个本地分支，命名 feature/xxx/functionA（feature/git账户/功能说明）
2.本地分支开发完，本地自测
3.feature分支合并到dev，发布qa环境验证，验证通过
4.从master重新拉一个release分支，命名release/2022-02-23.001 分支
5.把feature分支合并到release分支，在stage环境验证
6.stage验证通过后，release/2022-02-23.001分支打tag
7.tag版本直接发pro环境
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
