史上最全分支管理模型总结（某新势力车企）

某新势力车企采用了多分支管理策略，主要分为主分支、开发分支、预发布分支、特性分支和热修分支。其分支模型按代际进行划分，每个代际的分支模型与Git Flow基本一致。该模型在提高代码隔离和质量方面有一定优势，但在多项目并行情况下存在较高的同步成本和进度冲突问题。

分支定义

主分支

• 名称: master+代际
• 功能: 功能稳定分支
• 数量: 2
• 生命周期: 常驻
• 创建: 不涉及
• 消亡: 不涉及
• 提交: 不允许
• 同步: 手动
• 标记: 不涉及
• 质量: QA测试

开发分支

• 名称: dev+代际
• 功能: 最新功能分支，开发分支
• 数量: 2
• 生命周期: 常驻
• 创建: 自代际master拉出
• 消亡: 不涉及
• 提交: 不允许
• 同步: 手动
• 标记: 不涉及
• 质量: 不涉及

预发布分支

• 名称: release+代际+其它
• 功能: 预发布分支
• 数量: 多个
• 生命周期: 常驻
• 创建: 自代际dev拉出
• 消亡: 不涉及
• 提交: 允许，仅bug fix
• 同步: 手动
• 标记: 版本号
• 质量: CR

特性分支

• 名称: feature/xxx
• 功能: 新功能开发分支
• 数量: 多个
• 生命周期: 临时
• 创建: 自代际dev拉出
• 消亡: 合入代际dev
• 提交: 允许
• 同步: 手动
• 标记: 关键字
• 质量: CR

热修分支

• 名称: hotfix
• 功能: 功能发布分支
• 数量: 多个
• 生命周期: 长期
• 创建: 自代际master拉出
• 消亡: 合入代际master
• 提交: 允许
• 同步: 手动
• 标记: 关键字
• 质量: CR

说明

• 代际: 车企通常按代际划分软件架构平台，调研的新势力车企一代平台和二代平台在硬件、软件、电驱系统和电池技术等多个方面都存在明显的差异，这些差异旨在改进车辆的安全性、舒适性和性能。目前三代平台正在研发中，同时未来也发布了整车全域操作系统。一旦平台架构升级，新车型都会基于新平台开发。
• 代码: 不同代际的应用代码允许存在差异，目前也暂未要求代码统一，相当于一代一套代码。
• 同步策略: 为手动，经沟通确认目前某新势力车企在多项目并行开发方面并没有明确的同步策略。
• 调研模型: 来自某新势力车企智驾领域，该领域包括前端座舱应用及云端服务，后端分支模型管理未区分代际、发布分支为常驻分支且数只有一个，与Git Flow模型基本一致，在此不再列出。

工作流程

交付流程

1. 公司没有统一交付体系，各团队差异很大，有的团队在实践单团队敏捷。
2. 车型研发以项目制运行，走纯瀑布流程。如下为交付流程的简要描述：

分支管理

如上图所示，某新势力车企分支模型的特点是每个应用按照代际拆分出来两套分支独立演进，每个代际下的分支模型与Git Flow模型基本一致，此处不再列出具体的流程，主要说明其与Git Flow的差异点如下：

1. 模型说明:
   • 发布分支按车型拉出，经验收测试后长期存在。
   • 主分支上保存随时可向车型部署的版本，但运维基于release分支。
   • 在线上运维时hotfix之后的分支追平同步策略无规范，但从模型上推断是基于车型release分支，否则无法在保证质量的前提下向其他车型release分支横展。
2. 优劣势分析:
   • 优势: 各车型项目对应不同的release分支，相应代码的问题影响能够实现绝对隔离。
   • 劣势: 多项目并行情况下会遇到诸多无法解决的问题，具体包括:
     • 成本高: 如果同一时间内在并行进入QA测试的车型项目，在开发质量不理想时，分支之间需要进行频繁地同步追平，复测以保证质量。尽管可以规定以某车型为主解决问题，但是又会导致其它车型项目的测试问题阻塞，进而影响测试进度。
     • 进度冲突: 如上面在成本问题的描述，当多项目同时进入发布时，因为其多发布分支的解决问题需要大量的同步且，可能面临较大的同步成本，会导致车型项目提交测试问题解决的代码版本的冲突或等待，进而影响测试进度。

总结

该新势力车企通过明确的分支定义和管理策略，有效应对复杂的需求和技术挑战，一定程度上是有助于提升整体开发效能和产品质量的。然而这个分支模型在多项目并行开发时，仍会面临较高的同步成本和进度冲突问题。未来如果能够进一步优化分支管理策略，明确同步规则，将有助于提升团队协作效率，推动企业在激烈的市场竞争中保持领先地位。