git 分支规范
背景
产线当前在代码库管理遇到了如下挑战：
- 职责权限不明确，关键操作未收口，分支管理效率不理想。
- 多功能同时开发时，有功能之间互相Block、提测受影响、新分支建立困难的问题。
- 无法应对后续应对多客户定制化开发场景的需要。
- 测试团队人力紧张。
针对以上问题，本模型在旧模型的基础上进行改造，做出以下改变：
- 分支和tag建立收口到专人负责，不用再互相等待。
- 多feature并行开发测试，减少开发阶段的耦合。
- 设立定制化feature机制应对后期多客户的场景。
- 功能测试收束至develop分支进行。
实操
搬运一下我们团队的分支管理办法，大体的思路还是遵循git flow的规范
develop和release
当数个feature开发并提测后，进入多feature集成测试阶段。在develop分支进行多feature集成测试，完成后转入实验局测试。完成实验局阶段后，产品团队决定发版，这时从develop拉出release分支并根据版本号命名。此时会做最终的功能集成测试和回归测试，验证功能间是否有冲突导致的BUG和遗漏BUG，测试完成后合并至master和develop分支。
步骤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判断是否需要进行合入。
步骤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分支。
步骤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分支。
步骤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分支的日常测试活动 |