史上最全分支管理模型总结（某互联网大厂）

今天和大家分享的是某互联网大厂的分支管理规范。该企业采用了大规模敏捷（LeSS）框架，通过明确的分支定义和管理策略，确保了高效的产品迭代和技术交付。其分支定义包括主分支、集成分支、支持分支、发布分支和热修分支，每个分支都有明确的生命周期和质量保障措施。交付流程涵盖了从需求优先级确认到正式发布的各个环节，充分利用自动化工具提升发布效率和质量。

分支定义

主分支

• 名称: master
• 功能: 主要分支，随时可向生产环境部署。
• 数量: 1
• 生命周期: 常驻
• 创建: 初始化
• 消亡: 不涉及
• 提交: 不允许
• 同步: 不涉及
• 标记: 版本号
• 质量: 定期接口测试、性能测试、混沌测试（探索），上述活动发现的问题会根据规则建问题单并定级，根据级别决定是走hotfix还是排入迭代

集成分支

• 名称: ci
• 功能: 集成分支，体现最新的功能变化
• 数量: 1
• 生命周期: 常驻
• 创建: 初始化
• 消亡: 不涉及
• 提交: 不允许
• 同步: 不涉及
• 标记: 需求编号、日期及构建次数标识
• 质量: CR/静态扫描/自动化测试，流量回放测试

支持分支

• 名称: feature
• 功能: 用于开发新功能的分支，除了最新功能需求外，还包括非紧急问题、技术债务/优化任务。
• 数量: 多个
• 生命周期: 临时，在迭代启动会提前规划并对应到上线窗口
• 创建: ci
• 消亡: 合入ci后删除
• 提交: 允许
• 同步: ci，推荐开发期间定期同步
• 标记: 不涉及
• 质量: CR，静态扫描

发布分支

• 名称: release
• 功能: 用于提交给测试人员进行功能测试，以准备新的可发布版本。
• 数量: 1
• 生命周期: 常驻
• 创建: ci
• 消亡: 不涉及
• 提交: 不允许，问题需要再开发分支确认修复后再合入
• 同步: 不涉及
• 标记: 版本号+日期
• 质量: 自动化测试，QA人工测试

热修分支

• 名称: hotfix
• 功能: 用于对线上版本发现的高优问题进行bug修复
• 数量: 多个
• 生命周期: 临时，修复完成后删除
• 创建: master
• 消亡: 合入 master 后删除
• 提交: 允许
• 同步: 不涉及
• 标记: 版本号+sp+序号
• 质量: CR/QA人工测试/产品验证

工作流程

交付流程

某互联网大厂内部的商业SaaS方向的敏捷实践采用的是大规模敏捷（Large-Scale Scrum，简称LeSS）框架。LeSS又分为LeSS和LeSS Huge框架，就是某一个大的业务领域（通常8个敏捷小组，每个小组8人起）统一规划迭代交付的节奏和步调。

具体到双周的迭代交付流程如下：

1. 整个部门按统一节奏实行Release Train制度，所有小组共同计划、承诺、执行、检视和调整。

2. 团队规模：6个业务领域，13个敏捷小组，自有研发+QA+外包+运维约200人

3. 流程规范：

   • 要需求适应节奏，不要节奏适应需求
   • 关键环节时间固定，不允许延迟改期
   • 如有需求达不到准入标准，调整其它需求
   • 如有需求无法本迭代交付，调整到下迭代

4. 部门级关键活动说明：

   • 计划会
     • Guidance（Pre Plan）：由产品Head/Architect、研发Head/Architect发布迭代指引
     • Plan I& Plan II：由ASO/ATP整理并汇报当前迭代计划（Spring Backlog），介绍本迭代产品交付增量计划内容，在计划中要分析跨业务域的依赖，以及本迭代的人员供给情况等信息。Plan II主要讲与Plan I的Diff，包括需求项的增/删，Hard/Soft Commit项的变更等
   • 部门级每日站会：部门负责人，研发Head、产品Head、QA Leader、UE Leader每日早进行15分钟站会通报交付进展及运维事项
     • 线上问题：过去24h线上紧急且重要问题、超期三天问题、整体问题解决状况和进展
     • 关键项目：项目进展通报，主要问题解决情况、风险减缓措施推进情况同步
     • 各业务域/敏捷小组：各域Update，包括特别关键的进展通报，不同域之间的工作协同（特别是推进缓慢需要上升的问题，但需要其它域提前知晓协同的heads up。
     • 迭代交付进度同步：Release Manager进行部门本迭代交付燃尽图分析、上线回顾总结数据通报及问题点名；在迭代内部RM还会关注迭代需求的变更情况，以便确保时间盒内的任务达成的可能性
   • 迭代回顾：主要关注上个迭代各敏捷小组整体工作（做的好的、需要改进的，敏捷机制和团队合作要提升的）
   • 上线复盘：针对上线过程中遇到的问题进行根因分析并讨论解决方案，主要关注各组上线、验证时长超长情况，待办事项由相关人跟进，下迭代要看是否有提升效果
   • 迭代回顾：跨业务领域间的待协调事项的决策及问题解决

5. 敏捷小组级活动说明：迭代计划、每日站会、迭代回顾

分支管理

迭代交付

1. 初始化：初始化项目为gitflow，默认创建master分支，然后从master拉取第一个develop分支：

   git checkout develop; 
   git pull
   git checkout -b "feature/<description name of branch>"
   

2. 开发：

   • 开发准备：从develop拉取feature分支进行编码开发（多个开发人员拉取多个feature同时并行开发，互不影响）：

     git flow feature
     

   • 自测完成：
   • 合并到develop（不推送，feature功能完成还未提测，推送后会影响其他功能分支的开发）：

     git push origin feature
     git checkout develop
     git merge feature
     

   • 合并feature到develop，可以选择删除当前feature，也可以不删除，但当前feature就不可更改了，必须从release分支继续编码修改

3. 提测：

   • 从develop拉取release分支进行提测，提测过程中在release分支上修改bug：

     git checkout develop
     git pull
     git flow release start '1.0.0'
     

4. 上线：

   • 从release分支上线，上线后合并release分支到develop/master并推送：

     git flow release finish '1.0.0'
     

   • 合并之后，可选删除当前release分支，若不删除，则当前release不可修改，线上有问题也必须从master拉取hotfix分支进行修改

问题修复

1. 开发：Hotfix分支拉出：上线之后若发现线上bug，从master拉取hotfix进行bug修改：

   git fetch origin
   git flow hotfix start '1.0.1' '1.0.0'
   git push origin hotfix/1.0.1
   

2. 上线：直接在hotfix分支提测，通过测试后上线，上线后验证无问题再合并hotfix分支到develop/master并推送：

   git push origin develop
   git checkout master
   git push origin master
   git push --tags
   

3. 上线后：上线后已经完成hotfix分支到master分支的合并，合并之后可选择删除当前hotfix分支，若不删除则1. 当前hotfix不可修改。，若补丁未修复，则需要从master拉取新的hotfix继续进行修改

4. 追平：
   a. 开发期间追平：当进行一个feature时，若develop分支有变动，如其他开发人员完成功能并上线，则需要将完成的功能合并到自己的分支上，即合并develop到当前feature分支
   b. 测试期间追平：当进行一个release分支时，若develop分支有变动，如其他开发人员完成功能并上线，则需要将完成的功能合并到自己分支上，即合并develop到当前release分支（因为当前release分支通过测试后会发布到线上，如果不合并最新的develop分支就会发生丢失代码的情况。

总结

一些熟悉我的朋友应该知道文章里所说的互联网大厂是指哪个了。在 2020-2022 年进行了包括上面分支管理规范在内架构重构、组织调整以及稳定性治理等一系列效能改进措施之后，团队发生了很大的变化：由原来的上线频繁失败，每到上线日必加班到凌晨，到后来的每周一个上线窗口、九点前准时结束；从原来在 MEG 的效能垫底，到各项效能指标在 MEG 位列前茅；从原来的需求交付频繁延期，到连续的必报需求全部交付、承诺必达；从原来的频繁被投诉，到业务满意度半年提升了 10 个百分点。
科学的分支管理和交付流程是高频率、高质量的产品发布的基础，能够帮助我们有效应对复杂的需求和技术挑战。尽管在原 VP 转到 IDG、项目完成之后，核心团队还是没能逃过被后来的VP、总监清洗的结果，但是对于自己有幸成为这支能打硬仗、能打胜仗的团队之一员，甚至这大部分的成绩都有自己的深入参与，仍感觉到特别骄傲，以及怀念。