hexo-blog/source/_posts/git分支规范.md

title: git 分支规范 author: Gamehu tags:

• git categories:

• 工作

  date: 2019-03-15 14:54:00

  背景

产线当前在代码库管理遇到了如下挑战：

1. 职责权限不明确，关键操作未收口，分支管理效率不理想。
2. 多功能同时开发时，有功能之间互相Block、提测受影响、新分支建立困难的问题。
3. 无法应对后续应对多客户定制化开发场景的需要。
4. 测试团队人力紧张。

针对以上问题，本模型在旧模型的基础上进行改造，做出以下改变：

1. 分支和tag建立收口到专人负责，不用再互相等待。
2. 多feature并行开发测试，减少开发阶段的耦合。
3. 设立定制化feature机制应对后期多客户的场景。
4. 功能测试收束至develop分支进行。

实操

搬运一下我们团队的分支管理办法，大体的思路还是遵循git flow的规范

develop和release

当数个feature开发并提测后，进入多feature集成测试阶段。在develop分支进行多feature集成测试，完成后转入实验局测试。完成实验局阶段后，产品团队决定发版，这时从develop拉出release分支并根据版本号命名。此时会做最终的功能集成测试和回归测试，验证功能间是否有冲突导致的BUG和遗漏BUG，测试完成后合并至master和develop分支。

{% asset_img 1.png %}

• 步骤1

当新工程建立时，配置管理员从master分支拉出develop分支，设置保护权限，关闭develop分支所有人员提交代码权限，完成后邮件通知全体研发。

• 步骤2

当功能提测后，研发经理将feature分支合并至develop分支。若某feature分支未成功提测，则略过该分支。当全部feature分支合并完毕后开放develop权限。

每次测试部署时，由配置管理员建立tag，然后根据tag部署。

• 步骤3

重复BUG修复过程直至符合发布要求。

• 步骤4

当多feature集成测试阶段结束，配置管理员邮件通知全员即将锁定的分支，然后设置develop保护权限，建立tag进行实验局部署。

• 步骤5

实验局阶段将对bug进行整理，非block级bug将在后续feature中进行规划和修改。

注意事项：block级bug将视紧急程度开放权限给指定人员

• 步骤6

当产品团队确定发版，配置管理员从develop分支拉出release分支，邮件通知全员。

• 步骤7

集成测试部署时，配置管理员邮件通知全员即将锁定的分支，然后设置release保护权限，锁定release权限。（设置锁定的目的是防止转测阶段有人提交代码出现BUG，导致tag不可用）

• 步骤8

配置管理员在release上打测试tag，然后解除锁定，邮件通知全员。

研发下载release代码，准备修改bug。

测试经理基于测试tag，启动集成测试流程。

研发修复BUG并提交至release分支。

步骤7重复多次直到符合发布要求

| 角色 | 职责 | 通知机制 | | -------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | 研发经理 | feature分支向develop分支合并 release分支向master分支合并 release分支向develop分支合并 | feature分支的合并需要通知配置管理和Scrum Master release分支的合并需要通知配置管理 | | 配置管理 | develop分支的建立 release分支的建立、tag建立、锁定、删除 master分支的tag建立 feature分支的建立、tag建立、锁定、删除 | develop分支建立需要邮件通知全体人员 release分支的tag建立需要通知测试，release分支的建立、锁定、解锁需要邮件通知全体人员 master分支的tag建立需要通知负责安装包的研发人员 feature分支的tag建立需要通知测试， feature分支的建立、锁定、删除需要通知相关研发人员 | | 研发 | 开发、bugfix、安装包生成 | | | 测试经理 | release分支的测试、部署 feature分支的测试、部署 develop分支的测试、部署 | feature分支验收测试和多feature集成测试结果需要邮件通知对应研发和研发经理 |

hotfix分支场景

hotfix分支用于产品稳定版及现场问题的修正。当一线端反馈了BUG并且判定需要作为hotfix修复时，从master拉出hotfix分支。分支修复完成后，重新合并入master和develop分支。若hotfix可能影响定制化feature的场景，由ScrumMaster判断是否需要进行合入。

{% asset_img 2.png %}

• 步骤1

当master发布完成后，当有现场问题需要修正时，配置管理员从master的发布tag拉hotfix分支，邮件通知全员。

研发从hotfix分支下载代码，修改缺陷。

研发在实验局（建议）或专用环境验证缺陷是否修改完成。

研发将修改提交，然后推送到hotfix。

研发修改故障单状态，提交测试。

• 步骤2

在hotfix整体送测日，配置管理员锁定hotfix权限。

配置管理员在hotfix上打转测tag ，邮件通知全员。

测试经理基于转测试tag，启动回归测试流程。

如果回归测试不通过，配置管理员开放hotfix权限，重复步骤2直到回归测试通过。

• 步骤3

回归测试通过，测试经理确认基于hotfix的哪个tag发布，邮件通知全员。

执行步骤4、5、6，配置管理确定步骤完成后删除分支

• 步骤4

研发经理基于hotfix的发布tag，向master合并，完成后通知配置管理员。

配置管理员确认后，给master打发布tag，转升级包生成流程。

• 步骤5

研发经理基于hotfix的发布tag向develop合并，完成后通知配置管理员。

• 步骤6

配置管理员通知研发判断hotfix是否影响定制化分支，若影响，则通知研发经理基于hotfix的发布tag向定制化feature合并，完成后通知配置管理员和Scrum Master。

角色	职责	通知机制
研发经理	hotfix发布tag向develop分支合并 hotfix发布tag向master分支合并 hotfix发布tag向定制化feature分支合并	hotfix tag向develop和master的合并需要通知配置管理 hotfix tag向定制化feature的合并需要通知配置管理和Scrum Master
配置管理	hotfix分支的建立、锁定、删除 hotfix分支的tag建立 判断hotfix是否向定制化feature合并	hotfix分支的建立、锁定、解锁需要邮件通知全体人员 hotfix分支的tag建立需要通知测试经理 hotfix需要向定制化feature合并需要通知研发经理
研发	hotfix分支的日常实验局部署和bugfix 升级包生成
测试经理	hotfix分支的测试、部署 hotfix分支发布	hotfix分支发布需要邮件通知全体人员

feature分支场景

feature分支用于进行新功能开发和上个阶段实验局的缺陷修复。产线管理团队需要规划好功能的相关性和相互依赖，避免把相互依赖的功能放到不同的feature中去。在feature规划完成后，需要建立分支，并在feature分支上完成工程开发、提测阶段。提测成功后，feature分支将被合并至develop分支。

多个feature分支将在develop进行合并测试，若测试前有feature不满足提测条件，为了不影响其它feature的发布，可以将这个分支延迟合并。

注意事项：common包等不参与部署过程的公共模块，在产线管理团队规划时可采用其它的分支管理策略，例如多个虚拟团队公用一个feature分支。

{% asset_img 3.png %}

• 步骤1

当需求确定时，研发经理确定feature规划。feature规划一般根据敏捷小组进行，也会受到功能关联性的影响。feature规划确定后需要邮件通知研发小组和配置管理员。

• 步骤2

Scrum Master邮件发起feature分支建立申请，然后配置管理员从develop分支拉出feature分支，通知小组成员和研发经理。研发人员开始功能开发。

• 步骤3

准备提测，配置管理员锁定feature分支，通知小组成员、测试经理和研发经理。研发部署锁定的feature进行提测，不论提测通过或未通过，Scrum Master都解除分支锁定，通知小组成员和研发经理。

• 步骤4

若提测失败，配置管理员重新打开分支权限。

• 步骤5

研发继续在feature分支进行bugfix。当bugfix完成后，配置管理员重新锁定分支。

• 步骤6

提测通过，研发经理merge分支至develop。确定merge成功后，删除feature分支，通知小组成员和配置管理员。

• 步骤7

当第二个feature或者后续feature需要提测时，需要先从develop反向合并然后进行检查，该步骤是为了防止代码冲突或者功能被覆盖。

注意事项：若合并分支时发现基础代码有冲突，研发需要给测试团队提供冲突列表，帮助测试团队着重验证冲突功能。

角色	职责	通知机制
研发经理	确定feature规划 feature分支向develop分支合并 develop分支向feature分支合并	feature规划需要通知小组成员 feature分支的合并需要通知小组成员和配置管理员
配置管理员	feature分支的建立、tag建立、锁定、删除 develop的tag建立	feature分支的建立、tag建立、锁定、删除需要通知小组成员和研发经理
研发	feature分支的日常开发、部署和bugfix develop分支的实验局部署、多feature集成测试阶段bug修复
Scrum Master	发起feature建立申请	feature分支建立向配置管理员申请

定制化feature分支场景

当存在定制化需求时，需要建立定制化feature分支。该分支用于定制化客户的功能开发、测试、打包等。在定制化开发过程中，若有影响该分支的release和hotfix出现，则需要合入定制化feature分支。

{% asset_img 4.png %}

• 步骤1

定制化需求确定，配置管理员决定从哪个tag创建定制化feature分支。

• 步骤2

配置管理员从develop分支拉出定制化feature分支，通知相关小组成员和研发经理。

• 步骤3

当有release分支发布时，配置管理员决定是否合并至定制化feature分支，然后通知研发经理。

研发经理从release分支合并代码至定制化feature分支。

• 步骤4

当有hotfix分支发布时，配置管理员决定是否合并至定制化feature分支，然后通知研发经理。

研发经理从hotfix分支发布tag合并代码至定制化feature分支。

• 步骤5

准备提测，配置管理员锁定定制化feature分支，通知小组成员和测试经理。

• 步骤6

研发部署锁定的定制化feature进行提测，提测未通过，配置管理员解除分支锁定，通知小组成员。

• 步骤7

研发继续在定制化feature分支进行bugfix。当bugfix完成后，配置管理员重新锁定分支并且提测，通知小组成员、测试经理。

• 步骤6

提测通过，配置管理员对定制化feature分支建立tag，转安装包流程。

​

角色	职责	通知机制
研发经理	release分支向定制化feature分支合并 hotfix发布tag向定制化feature分支合并	定制化feature分支合并需要通知配置管理员
配置管理员	定制化feature分支的建立、锁定、解锁 定制化feature分支的tag建立	定制化feature分支的建立、锁定、解锁需要通知小组成员和研发经理
研发	定制化feature分支的日常开发、部署和bugfix
测试	定制化feature分支的日常测试活动

感谢：

{% blockquote 敏捷的水 https://www.cnblogs.com/cnblogsfans/p/5075073.html Git 在团队中的最佳实践--如何正确使用Git Flow deep-dive %}

{% endblockquote %}

{% blockquote Vincent Driessen https://nvie.com/posts/a-successful-git-branching-model/ A successful Git branching model %}

{% endblockquote %}