背景：为了更好长期维护项目开发，保持良好的代码提交记录以及 git 分支结构清晰，因此整理：git分支管理规范。

规范只是提供一定的参考及约束，遇到特殊场景，只需朝着利于长期维护管理的方向处理即可；

一、相关术语

为了先了解开发中常用到或者听到的术语，有利于更好里的理解后面的分支管理

简称	全称	文字描述	使用对象	用于	变动
dev	Development Environment	持续集成开发环境	研发人员	开发环境：单元测试，UI测试验证，前后端接口业务逻辑联调测试； 仅供内部人员访问；	最大
test	Test Environment	测试环境	测试人员	测试环境：需求业务逻辑集、UI测试，需求涉及功能点回归测试； 仅供内部人员访问；	较大
int	Integration Test Environment	集成环境	产品	各系统集成环境：对接的各系统集成之后最终环境，按照需求进行验证测试；	小
uat	User Acceptance Test Environment	用户验收环境	客户方	用户体验环境：按照需求功能文档进行验收； 产品、用户（客户方）直接参与测试	较稳定
pro	Production Environment	生产环境	真实客户	生产环境：根据实际业务需求使用，解决问题； 真实客户直接使用	稳定

二、分支管理

根据上面的环境术语，可得出不同的环境对应不同的分支命名规则，为了更好缺粉代码功能所属的环境，并且可以更好的解决针对不同环境，解决对应环境的问题，而不需要花费额外的时间寻找版本，commitId等信息；

分支	名称	对应环境
dev	需求开发分支	dev
hotfix	线上问题紧急修复分支	dev、test、int、uat、pro
test	测试验证分支	test、int
release	测试发布，预投入生产分支	uat
master	生产分支（主分支）	pro

1. master分支
   项目初始化之后，便需要创建 master 分支，如果项目对应多个产品的话，请根据产品信息建立对应的产品主分支如：productA_master；其他场景下，该分支的代码主要是由 release 分支 或者是 hotfix 分支合并，该分支不允许直接修改代码；

2. dev分支

   根据需求定义dev分之，实现需求业务逻辑；当需求版本投入生产稳定之后，即可删除；命名规范：productA_dev_{版本号}_分支特征_年(两位即可)月日，如：{productA}_dev_v2.0.0_broadcast_240130（2.0.0版本中的播报方式）；

3. test分支

   • 当dev分支开发完成并进行基本的集成测试，需求实现并测试通过之后，将dev分支的代码进行合并到test分支，供测试人员进行测试验证；测试人员提出的BUG，先在dev分支上修改验证通过之后，合并到test分支，测试人员在进行复测；
   • 测试人员整体测试验证通过，可将test分支提供给int环境，进行集成，产品人员进行测试验证，提出新的BUG，先在dev分支上修改验证通过之后，在此合并到test分支；命名规范： {productA}_test；

4. release分支

   • 当产品人员对集成环境测试验证通过之后，便可将test分支合并到release分支，此时uat环境对应的客户方便可介入测试验证，进行模拟生产实际业务，测试验收；若发现问题查实是BUG，研发人员在dev分支解决并回到第3节点test分支重新执行；
   • 当客户方介入验收成功之后，便可投入生产，若生产环境实际业务需求成功实现，便可将release分支代码进行合并到master分支；

5. hotfix分支

   • 该分支比较特殊，如果在生产环境出现紧急问题需要修复，研发人员需要基于master分支新建一个hotfix分支，解决生产紧急问题，然后直接将该分支提供给测试人员在test环境验证；int环境产品人员也同时进行测试验证；当前面两者环境验证没有问题，最终在uat环境验证测试通过之后，便可发布到生产环境；
   • 中间环节如果出现问题直接在hotfix分支上面修改；
   • 当分支成功投入生产之后，便可该分支合并进master，然后创建tag并删除该分支；

三、开发场景

3.1 新需求加入

加入有一个用户管理的新需求需要开发，分支命名可以是：dev_v2.1.0_userManager_240130 分支，基于哪一个分支需要根据不同场景进行判断：

1. 如果 存在未测试完毕 需求：
   • 新需求和未测试完毕的需求一同发布，则基于dev分支创建本次需求分支，最终该分支合并到未测试完毕的分支上；
   • 新需求和未测试完毕的需求不确定是否一同发布，则基于主分支master 分支进行创建，最终该版本和未测试完毕需求哪一个先上线，另一个则需要合并先上线的需求分支代码；
2. 如果不存在未测试完毕的需求：则直接基于master分支进行本次需求分支；

当本次需求分支开发完毕，并自行验证通过之后，便可准备提测（将需求功能、分支信息、commitId等信息提供给测试人员进行验证）;

1. 将dev需求分支代码合并到test分支（test环境）上；
2. 测试人员在 test （test环境） 测试通过后， 测试人员将包提供给支撑人员部署到int环境（集成环境），产品人员进行测试验收；
3. 当产品人员在test（int环境）测试验收通过之后，运维人员便可将包部署到uat环境（用户验收环境）供用户跑模拟实际业务的测试流程，同时研发人员将代码合并到 release （用户验收环境）；
4. 客户方在 release （用户验收环境）测试通过后，运维人员便可着手准备投入pro（生产环境），进行升级发布；
5. 当需求成功上线之后，便可基于 dev_v2.1.0_userManager_240130 创建一个tag，描述具体的功能点，然后dev_v2.1.0_userManager_240130 分支便可删除；

3.2 普通迭代

有一个用户管理的迭代需求，如果开发工时 < 1人/天（一个人开发一天），直接在 dev_v2.1.0_userManager_240131 开发，如果开发工时 > 1人/天（一个人开发一天），那就创建分支新的分支dev_v2.1.0_userManagerIterate_240131，在新分支上开发并进行测试验证通过之后，在合并到test分支。

注：开发后的提测上线流程 与（ 3.1） 章节新需求加入的流程一致。

3.3 修复测试和集成环境 Bug

测试人员（test环境）或者产品人员（int环境）提出的BUG，先在dev分支上修改验证通过之后，合并到test分支，测试人员（test环境）或者产品人员（int环境）在进行复测；

3.4 修改用户验收环境 Bug

在 release 测试出现了Bug，首先要回归下 dev 分支是否同样存在这个问题。

• 如果存在，修复流程 与（3.3）章节修复修复测试和集成环境 Bug流程一致。
• 如果不存在，大部分是历史数据问题，环境配置等造成的。

3.5 修改正式环境 Bug

在 master 测试出现了Bug，首先要回归下 release 和 test 分支是否同样存在这个问题。

• 如果存在，修复流程 与 修复测试环境 Bug流程一致。
• 如果不存在，大部分是历史数据问题，环境配置等造成的。

3.6 紧急修复正式环境 Bug

需求在测试环节未测试出 Bug，上线运行一段时候后出现了 Bug，需要紧急修复的。

• 如果 release 分支存在未测试完毕的需求，就基于 master 创建 hotfix-240131 分支，修复完毕后，临时更换一下uat环境对应的包（hotfix-240131 分支提供的包）进行验证，验证成功之后，投入pro生产成功，合并代码到master，将master 代码合并到release、 test和dev 分支 ，同时基于hotfix-240131 分支创建一个tag，描述具体的功能点，然后删掉 hotfix-240131 分支。
• 如果 release 分支不存在未测试完毕的需求，但 test 分支存在未测试完毕的需求，就基于 release 创建 hotfix-240131 分支，修复完毕后发布到 release 验证，后面流程与上线流程一致，验证完毕后，将 master 代码合并到test和dev 分支 ，同时基于hotfix-240131 分支创建一个tag，描述具体的功能点，然后删掉 hotfix-240131 分支。

3.7 并行提测

在一个项目中并行开发了两个需求，并行提测，但是上线日期不同，分支A先上线，分支B后上线;

• 基于后上线分支B的版本分支新建一个可供测试验证的测试分支C，并将提前上线的 分支A 合并到测试分支C上；
• 如果分支A出现BUG，研发人员现在分支A上调整之后再合并到测试分支C；如果分支B出现BUG，研发人员现在分支B上调整之后再合并到测试分支C；

以上内容是根据自己所接触项目实际场景整理的，欢迎提供建议，不断完善git分支管理规范；