史上最全分支管理总结（第二家新势力车企）

今天给大家带来的是另一家新势力车企的分支管理模型总结。该公司采用多分支管理策略，包括主分支、开发分支、发布分支和热修分支，同样也是按代际划分进行独立演进。其半敏捷流程结合平台化概念，旨在减少车型差异，提高代码质量和产品发布效率。然而，当前缺乏明确的多项目同步策略，存在一定的改进空间。

分支定义

主分支

• 名称: xxx_master
• 功能: 用于新车全量发布或新版本回带，绑定平台
• 数量: 多个
• 生命周期: 常驻
• 创建: 从上一代平台分支也可能重新拉
• 消亡: 不涉及
• 提交: 不允许
• 同步: 不涉及
• 标记: 车型+版本
• 质量: CR/自动化测试/QA测试/其它（不是特别完善），能够自动部署到台架。

开发分支

• 名称: xxx_develop
• 功能: 某一车型或者某一迭代新增功能
• 数量: 多个
• 生命周期: 常驻
• 创建: 上一代平台main分支，或者main分支
• 消亡: 不涉及
• 提交: 允许
• 同步: release/main
• 标记: 日期+版本
• 质量: Code Review、单元测试（联调）通过、QA测试

发布分支

• 名称: xxx_release
• 功能: 自全功能测试
• 数量: 多个
• 生命周期: 常驻
• 创建: 对于车型/平台main
• 消亡: 不涉及
• 提交: 允许
  1. bugfix需要通过cherry-pick提交开发分支
  2. 不同release分支间不merge，相同问题两边改
• 同步: 不涉及
• 标记: 日期

热修分支

• 名称: xxx_hotfix
• 功能: 热修复分支
• 数量: 多个
• 生命周期: 多个
• 创建: main分支拉出
• 消亡: 合入main分支后删除
• 提交: 允许
• 同步: 不涉及
• 标记: 不涉及

工作流程

交付流程

1. 半敏捷流程，在推平台化概念（以配置化为主），减少各车型的差异
2. 没有明确的敏捷节奏，但是相当于迭代/增量开发模式，开发一个批次功能之后提测，测试完成之后再启动下一批次的开发。无法走敏捷模式原因主要是因为测试问题排查时长不好把控。

分支管理

1. 主分支管理：
   • xx_master和整车架构平台对应: 可存在多个，主分支可以从上一代主分支拉出，也可能不继承上一代平台代码（主要取决于平台硬件架构差异有多大）
   • 不同平台分支之间允许存在差异: 一般不会做多平台并行开发，即拉出2.0分支之后就不会在1.0之上做新功能开发，仅解决问题。如果平台版本间差异不大，会考虑版本回带
   • 内部推进平台化: 通过热更新等手段来进一步降低回带升级成本，对于平台版本间的代码差异抹平也会有一定的帮助
2. 版本回带：
   • 指ROM升级之后对旧车型版本更新，通过持续的cherry-pick和测试来达到版本回带的目标。
   • 版本回带通过系统自动升级的方式进行，与SOTA、FOTA概念有所不同，该公司的SOTA、FOTA更多的是针对整车电气平台架构。
3. 同步追平：
   • 为了实现版本回带，要求在release/main分支的修改需要一处修改、多处提交（通过cherry-pick）
   • 开发主要是面向平台演进的，一般不会按车型拉release分支，而是按平台拉分支，测试主车型同时会针对旧车型进行版本回带测试。

总结

该公司分支管理模型在多个方面展现了优势。首先，分支定义和功能明确，包括主分支、开发分支、发布分支和热修分支，各分支的规则清晰，有助于开发团队理解和遵循。平台化和配置化的推进，减少了各车型之间的差异，提高了开发效率和代码复用性。热修分支管理确保了紧急修复的快速响应和干净的分支历史，而版本回带机制保证了旧车型用户的良好体验和版本一致性。此外，严格的质量控制和自动化测试与部署进一步提升了代码质量和系统稳定性。

然而，该公司的分支管理模型也存在一些改进空间。首先，尽管采用半敏捷流程，但缺乏明确的敏捷节奏，可以进一步引入Scrum或Kanban等敏捷方法。其次，发布分支之间不允许互相合并，导致重复劳动和维护成本增加，需要引入更多自动化工具和策略简化同步和整合过程。测试时间控制也是一个需要优化的方面，可以通过更高级的测试自动化工具减少排查时间，提高测试效率。进一步提升自动化水平，特别是在代码合并、冲突解决和回归测试方面，可以减少手动操作。分支命名规范和标准化也需要加强，以减少沟通成本。最后，加强跨团队的协作和知识共享，确保不同团队之间的最佳实践和经验能够得到充分利用和推广。