3. 版本分支策略：Git Flow、Trunk Based Development等主流分支模型在EPS项目中的选择与适配
版本分支策略，说白了就是团队怎么协作写代码的规矩。我见过不少EPS项目，一开始没定好分支策略，结果合并冲突比代码还多，发布时手忙脚乱。今天咱们聊聊几种主流模型，以及它们在EPS项目里怎么落地。
3.1 为什么EPS项目需要分支策略？
EPS软件不是普通的嵌入式系统。它涉及功能安全、多版本并行、长期维护。你想想看，一个车型可能同时有3个版本在开发：当前量产版、下一年小改款、下一代大改款。没有分支策略，代码库就是一团乱麻。
我个人习惯，在项目启动第一天就定好分支模型。因为后期改分支策略，成本极高。我曾经在一个项目里，团队用了半年的Git Flow，突然要切到Trunk Based，结果光迁移就花了两周，还丢了几个hotfix记录。
3.2 Git Flow：经典但偏重
Git Flow是2010年左右的经典模型。它有5种分支：master、develop、feature、release、hotfix。结构清晰，但流程较长。
| 分支类型 | 用途 | 生命周期 |
|---|---|---|
| master | 生产就绪代码 | 永久 |
| develop | 日常开发集成分支 | 永久 |
| feature | 新功能开发 | 短期（几天到几周） |
| release | 发布前准备 | 短期（几天） |
| hotfix | 紧急修复生产问题 | 极短（几小时到几天） |
在EPS项目中的适配：
- 适合场景：多版本并行维护、功能安全认证需要严格追溯的场景。比如一个EPS项目同时维护v1.0（量产）、v1.1（小改款）、v2.0（全新架构）。
- 避坑指南：我曾经见过团队把feature分支开了一堆，结果合并到develop时冲突不断。建议feature分支不要超过3天，否则就定期从develop rebase。
- 我的建议：如果团队规模小于10人，Git Flow可能太重了。release分支和develop分支的合并操作，每周至少多花2小时在分支管理上。
核心要点：Git Flow适合需要严格版本追溯的EPS项目，但不要滥用feature分支。每个feature分支应该对应一个JIRA ticket，合并时保留完整提交历史。
3.3 Trunk Based Development：轻量但要求高
Trunk Based Development（TBD）强调所有开发者在主干（trunk/main）上工作。分支只存在几小时，最多一两天。它要求团队有很强的持续集成能力和自动化测试覆盖。
在EPS项目中的适配：
- 适合场景：快速迭代、持续交付的EPS项目。比如互联网车企的OTA升级项目，每周都要发布新版本。
- 挑战：EPS涉及功能安全，有些修改需要评审和测试周期。如果所有代码都直接上主干，风险较高。
- 我的经验：我在一个EPS项目中尝试过TBD，但发现功能安全相关的代码（比如扭矩监控模块）还是需要走分支评审。后来我们做了折中：普通代码走TBD，安全关键代码走短分支（最多1天）。
实用技巧：如果选择TBD，一定要配上feature toggle（特性开关）。这样不完整的代码可以合入主干，但通过开关控制是否生效。我习惯用配置文件+编译宏双重控制，确保安全。
3.4 其他分支模型
除了上面两种，还有几个模型值得了解：
- GitHub Flow：简化版Git Flow，只有master和feature分支。适合小型团队，但EPS项目用起来有点吃力，因为缺少release分支管理。
- GitLab Flow：在GitHub Flow基础上增加了环境分支（如staging、production）。适合有明确部署环境的EPS项目。
- Release Branching：以发布为中心，每个版本一个分支。适合长期维护的EPS产品，比如一个EPS平台要支持5年。
3.5 EPS项目的选择与适配建议
说了这么多，到底怎么选？我根据经验总结了一个决策矩阵：
| 项目特征 | 推荐模型 | 原因 |
|---|---|---|
| 多版本并行维护（3个以上） | Git Flow | release分支和hotfix分支能清晰管理每个版本 |
| 快速迭代（2周内发布） | Trunk Based | 减少分支合并开销，加速交付 |
| 功能安全要求高（ASIL-D） | Git Flow + 短feature分支 | 需要严格评审和追溯，但分支不宜过长 |
| 团队小于5人 | GitHub Flow | 简单够用，减少管理成本 |
| OTA持续交付 | Trunk Based + feature toggle | 支持频繁发布，同时控制风险 |
重要提醒：不要照搬理论模型。我曾经见过一个团队严格按照Git Flow的图来操作，结果每次合并都要开5个分支。记住，分支策略是为项目服务的，不是反过来。根据实际情况做裁剪，比如去掉release分支，用tag代替。
3.6 实战：EPS项目的分支命名规范
不管选哪种模型，分支命名规范一定要统一。我推荐以下格式：
# 功能分支
feature/EPS-1234-add-torque-sensor-support
# 修复分支
fix/EPS-5678-fix-overcurrent-protection
# 发布分支
release/v1.2.3
# 热修复分支
hotfix/v1.2.1-critical-safety-fix
# 实验分支
experiment/steering-angle-prediction-v2嗯，这里要注意：分支名里一定要包含JIRA ticket号。这样追溯起来特别方便。我曾经在一个项目里，没有加ticket号，结果半年后看分支，完全不知道当时为什么要改。
3.7 我的最终建议
如果你现在要启动一个EPS项目，我建议这样：
- 起步阶段：用Git Flow的简化版（master + develop + feature + hotfix）。去掉release分支，用tag代替。
- 团队成熟后：逐步向Trunk Based过渡。先让非安全关键模块走TBD，安全模块保持短分支。
- 长期维护：建立分支清理机制。每周清理一次已合并的分支，避免分支泛滥。
记住，没有完美的分支策略，只有适合当前团队和项目的策略。多试、多调整，找到自己的节奏。