git分支管理规范整理_git 分支管理规范

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

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

一、相关术语

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

二、分支管理

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

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分支管理规范；