📚 课程目录第4章 AURIX软件仓库与分支策略设计

4. AURIX软件仓库与分支策略设计

AURIX TC3xx 系列通常包含多个 TriCore 核（如 CPU0/CPU1/CPU2 加锁步核）、多个外设簇（GTM、ADC、CAN、以太网等），并且一个量产项目往往同时存在应用层、基础软件层、MCAL 配置层、供应商交付包和多个变体（不同整车厂、不同硬件版本）。如果仓库结构设计不当，最先出问题的不是编译，而是“改错分支、合错版本、供应商包被覆盖、量产版本无法追溯”。本节从仓库组织、分支模型、子模块与供应商代码、量产与维护分支治理四个层面给出可落地的设计方法。

一、多核多项目代码组织：按“可独立交付单元”切分仓库

常见的错误做法是把所有项目、所有核、所有配置都塞进一个仓库，用目录区分。这样做的后果是：一个项目的配置改动会污染其他项目的构建缓存，分支切换时大量无关文件变动，代码评审难以界定影响范围。更合理的做法是按“可独立交付单元”切分，形成“平台仓库 + 项目仓库 + 供应商仓库”的三层结构。

平台仓库承载与具体项目无关的公共能力：AUTOSAR 基础软件（BSW）适配层、多核启动与核间通信（如 Spinlock、Ipc）、公共驱动封装、构建脚本与 CI 流水线定义。项目仓库承载具体量产项目的配置与集成：MCAL 配置（EB tresos 生成的 .arxml 与生成代码）、OS 配置、项目专属应用逻辑、链接脚本与内存映射（LMU、DSPR、PSPR 分配）。供应商仓库承载第三方交付的二进制库、头文件、文档与许可证，保持原样、只读引用。

多核代码的组织建议按“核职责”而非“文件类型”划分目录。例如 CPU0 负责启动与安全监控，CPU1 负责控制算法，CPU2 负责通信与诊断，则项目仓库中可设置 core0_boot/、core1_control/、core2_comm/，每个目录内再分 src/、cfg/、test/。这样在代码评审时，通过目录即可判断改动影响哪个核，也便于为不同核设置独立的静态检查规则。

二、Git 分支模型：以量产可追溯为核心

AURIX 量产软件的 Git 分支模型不应照搬互联网的 Git Flow，而应以“任一量产版本都能从标签回溯到确定的分支与提交”为核心目标。推荐采用“主干 + 发布分支 + 维护分支 + 特性分支”的模型。

main 为主干，始终保持可编译、可运行基础冒烟测试；release/Rxx.yy 为发布分支，从 main 在功能冻结点切出，只接受缺陷修复，不接受新功能；maint/Rxx.yy 为维护分支，用于量产后的长期维护，与 release 分支一一对应；feature/xxx 与 bugfix/xxx 为短生命周期分支，合并后即删除。每个量产交付点必须在 release 或 maint 分支上打标签，标签命名建议为 REL_<项目>_<版本>_<日期>，例如 REL_VCU_1.2.0_20250612。

关键约束是：禁止在 release 分支上直接提交，所有修复必须经 bugfix 分支合并；禁止用 rebase 改写已推送的 release/maint 历史；合并到 release 必须经过代码评审与 CI 门禁。这样，当客户反馈某个量产版本问题时，可以通过标签精确定位到提交，再判断该修复是否已进入其他维护分支。

三、子模块与供应商代码管理

供应商代码（如 MCAL 交付包、AUTOSAR BSW 二进制、加密库）通常体积大、更新频率低、不允许修改。推荐用 Git 子模块（submodule）或包管理方式引用，而不是直接复制进项目仓库。子模块方式下，项目仓库只记录供应商仓库的提交哈希，供应商更新时只需更新子模块指针，评审时能清晰看到“从哪个供应商版本升到哪个版本”。

子模块的常见坑是“忘记初始化”和“指针漂移”。CI 中必须显式执行 git submodule update --init --recursive，并在流水线中校验子模块指针与预期版本一致。对于不允许外网访问的供应商仓库，可搭建内部镜像，子模块 URL 指向镜像地址。供应商代码目录应设置只读权限，任何本地修改都会在 CI 中被检测并拒绝。

# 添加供应商 MCAL 交付包为子模块
git submodule add https://git.internal/supplier/mcal_tc3xx.git vendor/mcal_tc3xx
git commit -m "引入 MCAL TC3xx v2.3.1 交付包"

# CI 中初始化并校验子模块版本
git submodule update --init --recursive
git submodule status | grep -v "$(cat .submodule.lock)" && exit 1

四、量产分支与维护分支治理

量产分支治理的核心是“冻结、追溯、可控回灌”。功能冻结后，release 分支只接受经评审的缺陷修复；每个修复必须关联缺陷编号、影响分析与回归测试记录。维护分支用于量产后的长期支持，通常按“一个量产项目一个 maint 分支”或“一个平台版本一个 maint 分支”管理，具体取决于项目数量与差异度。

回灌策略需要明确：maint 分支上的修复应定期合并回 main，避免主干丢失量产修复；但合并前必须确认该修复不依赖 maint 分支特有的配置。建议在 CI 中设置“回灌检查”，当 maint 分支有新提交且超过约定周期未回灌 main 时，自动提醒负责人。

治理要点：release 与 maint 分支应设置保护规则，禁止直接 push；标签一旦创建不可删除或移动；供应商子模块指针变更必须走独立评审；每个量产标签必须附带构建产物哈希与测试报告链接。

最后，分支与仓库设计不是一次性的，应随项目数量增长定期复盘。当项目仓库数量超过维护能力时，可考虑将公共配置进一步下沉到平台仓库，或引入配置生成工具，用参数化方式减少重复。判断标准很简单：如果两个项目 80% 以上的代码相同，差异只应体现在配置与少量项目专属代码上，而不是两份几乎相同的仓库。