git版本代码管理规范示例图

这里根据项目的进度和项目的人员规划，设计了几个不同的方案。仅供参考。

---

背景

背景：随着业务以及需求迭代比较多。针对一个服务，可能需要多人之间协作开发完成。多人协作开发过程中，如果命名不做统一规范，或者分支使用不做统一规范，在后续测试，打版本，发生产过程中会造成混乱，可能会出现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环境