Git版本管理流程与规范-生活圈
分支定义及含义说明
分支流程中包含5类分支，分别是master、release、test、dev、hotfix，各类分支作用和生命周期各不相同。
【master 】：（仅一个）该分支是线上稳定版本代码，禁止提交代码；对于各种库的依赖都需要依赖此分支，需求上线时从dev分支直接合并到master分支；
【dev 】：开发分支（有多个），从master分支切出，是需要开发代码的分支，所有开发均在dev分支；
【test 】：测试分支（仅一个），首次从master切出，需求提测时从dev分支合并到test分支进行测试；
【release】：预发布分支（仅一个），首次从master分支切出，需求上线前从dev合并到release分支，部署到预发布环境，进行上线前测试（暂时缺少此环境，预留此分支）；
【hotfix 】：有多个，从master分支切出，解决线上紧急BUG的修复。
分支命名规则
dev开发分支命名规则：
基础分支可以命名为：dev
迭代需求的支命名方式：dev-${APP版本号}，如：dev-803（表示：APP的8.03版本）；
正常需求分支命名方式：dev-${需求名}，如：dev-life（生活号需求）、dev-ux（UX迭代需求）
hotfix分支命名规则：
hotfix-${日期}，如：hotfix-20210813
代码提交示例
角色及职责定义
模块的开发组员：maintainer
dev、hotfix的分支开发
模块的开发负责人（组长/模块负责人）：Owner
从master 打 dev、test、release、hotfix 分支
dev、hotfix的分支开发
从dev分支合并到test
从dev分支合并到master
将master合并到各个dev分支
删除hotfix分支
分支记录存放位置 - Git->wikis->分支记录
版本号规范
dev、test及release版本号命名规则 - <主版本号>.<副版本号>.<发布号>
主版本号设置规则
产品的主体构件进行重大修改，主版本号加1
产品的主体构件之间的接口协议重大修改，主版本号加1
副版本号设置规则
主版本号变更时，副版本号置0
数据结构变更(新增或修改注释含义的情况除外)，副版本号加1
若副版本号累加至超过90时，采用主版本号进位制，主版本号加1，副版本号重新置0
发布号设置规则
主版本号或副版本号变更时，发布号置0
若发布的版本无数据结构变更，则发布号加1
hotfix版本号命名规则 - <主版本号>.<副版本号>.<发布号>
hotfix由于即修即删，因此同release版本的版本号即可
说明：主版本号和副版本号的变更标志着重要的功能或结构变动。发布号的变更，用于体现小的功能变更
各种场景流程规则
当需要开发常规迭代时：
从master分支创建dev分支，例如：dev1.3.0；
在dev分支上开发代码，push到远程仓库；
dev分支代码开发完毕，合并到release分支，例如：release1.3.0 <开发组长/模块owner>；
测试人员在release1.3.0分支进行测试，测试完毕后拿release1.3.0分支部署；
上线验收完毕后将release1.3.0分支合并到master分支；
正常开发常规版本流程
紧急&BUG修复版本流程规则
当需要修复线上紧急BUG时：
从master分支创建hotfix分支；
在hotfix分支修复BUG，push到远程仓库；
BUG修复完毕后，合并到test测试分支进行测试，例如：hotfix-20210813合并到test分支 <开发组长/模块owner>；
测试人员在test分支进行测试，测试完毕后拿hotfix分支合并到master进行部署；
上线验收完毕后将master分支合并到各个dev分支；
当需要修复线上紧急BUG流程图：
注意事项
dev分支之间不能合并代码
release分支不能合并到dev分支
从dev分支合并到test分支测试时，只能合并dev分支上自己的commit到test，可参考git cherry-pick、git rebase命令
如发现当前test分支测试时，落后于master一个版本及以上，需要将master合并至当前test分支；
严禁直接在test、release、master分支进行需求开发和修改bug，特殊情况除外；
只有需求到提测日期才需要把开发分支的代码合并到测试分支test上；
需求提测后如需要修改bug，在原来的dev分支修改，然后合并到test分支进行测试；
相关环境
预发布环境
生产环境
开发环境
测试环境
举例说明（以803版本需求为例）
web-api 和 lib-service 项目现基于master分支创建了 test分支和dev-803分支，
test分支：测试分支，替换现有的testenv分支，
dev-803分支：803版本的需求开发的代码提交到此分支；
开发阶段把代码提交到dev-803分支，在本地开发联调通过后 并到达提测日期时再合并到test分支上；未到提测日期请不要合并到test分支；
803版本测试阶段，修改bug还是在dev-803分支提交，然后再合并到test分支进行测试；
当803版本达到上线标准时，直接把dev-803分支合并到master分支
