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 %}