3. 座舱软件版本与分支管理策略

座舱软件不是单一代码库，而是由高通基线、车厂定制层、应用功能层和发布交付层叠加而成的多源体系。分支管理如果只按“开发、测试、发布”三条线粗放划分，很快会出现基线漂移、补丁丢失、定制冲突和追溯断链。本节围绕高通基线版本、车厂定制分支、功能分支与发布分支的规划，以及版本命名与追溯规则，给出一套可直接落地的组织方式。

一、四类分支的职责边界

座舱项目的分支体系通常由四类分支构成，它们不是并列关系，而是“上游供给—定制叠加—功能开发—发布冻结”的层次关系。

• 高通基线分支（baseline）：对应高通发布的 BSP/HLOS 版本，例如 qcom/msmnile/LA.UM.9.12.r1-08000。它是只读上游，不允许车厂直接在其上提交业务代码，只允许以补丁或 cherry-pick 方式引入高通后续修复。
• 车厂定制分支（platform/custom）：从某个高通基线切出，承载车厂硬件差异、HAL 适配、开机动画、系统裁剪、安全策略等平台级定制。它对应“一个车型平台一条定制线”。
• 功能分支（feature）：从车厂定制分支切出，承载单个功能或单个域的开发，例如 feature/hmi-launcher、feature/audio-zone、feature/carplay。生命周期短，合并后即删除。
• 发布分支（release）：从车厂定制分支在某个冻结点切出，只接受缺陷修复和发布相关变更，不接受新功能。它对应“一个可交付版本一条发布线”。

关键原则是：功能分支只向定制分支合并，发布分支只从定制分支切出并只接受修复。任何跨层直接提交都会破坏追溯链。

二、版本命名与追溯规则

版本命名必须同时承载“平台、基线、定制、发布”四层信息，否则追溯只能靠人工翻记录。推荐采用如下命名格式：

<平台代号>-<基线版本>-<定制序号>-<发布序号>
示例：8295-LA.UM.9.12.r1-08000-C03-R05

8295        : 车型平台代号（对应车厂定制分支）
LA.UM.9.12.r1-08000 : 高通基线版本
C03         : 车厂定制分支第3次平台级变更
R05         : 该定制线上的第5个发布版本

对应的 Git 标签建议使用 v8295-C03-R05，并在标签注释中写入：基线 commit、定制分支 HEAD、发布分支 HEAD、关联的高通补丁列表。这样任何一个发布版本都能通过标签注释反向定位到完整来源。

追溯规则要落到三个具体动作上：

1. 基线变更必须记录补丁号：每次从高通引入修复，在定制分支的提交信息中写明 QCOM-PATCH: <补丁编号>，便于后续核对是否遗漏。
2. 功能合并必须关联需求号：功能分支合并到定制分支时，提交信息包含 FEATURE: <需求ID>，发布时可按需求号筛选变更集。
3. 发布分支只接受修复提交：修复提交信息包含 FIX: <缺陷ID>，并注明影响的发布版本范围，避免修复漏合到其他发布线。

三、分支规划的实际操作要点

规划阶段最容易出问题的是“定制分支与发布分支的切出时机”。建议以车型平台的软件冻结点为界：冻结前，所有功能在功能分支开发并合并到定制分支；冻结时，从定制分支切出发布分支，此后定制分支继续接受下一版本的功能，发布分支只接受修复。这样定制分支始终向前，发布分支保持稳定。

另一个要点是基线升级策略。高通基线不会频繁大版本跳变，但会持续发布补丁。建议每季度评估一次基线补丁合并，合并时在定制分支上以独立提交完成，并打上 baseline-sync-YYYYQN 标签。这样当某个发布版本出现底层问题时，可以快速判断是否与某次基线同步相关。

四、版本命名与追溯检查表

发布前可用下表快速核对版本命名与追溯信息是否完整。表中字段为示例，实际项目可按平台调整。

把上述规则固化到 CI 流程中，可以在每次打标签时自动校验版本号格式、标签注释完整性和提交信息关键字。校验不通过则拒绝生成发布包，从机制上保证追溯链不断裂。分支管理的价值不在于分支数量，而在于每个版本都能被准确还原、每个变更都能被定位来源。