2、版本管理基础：为什么ADAS需要版本管理、版本号命名规范（语义化版本）、版本管理工具选型（Git/SVN）
好，咱们正式开始聊版本管理。说实话，很多刚入行的朋友觉得版本管理就是「存个代码」，随便搞搞就行。但做ADAS系统，你试试看？一个版本搞错，车在路上识别错了障碍物，那可不是闹着玩的。
我个人习惯把版本管理看作是ADAS系统的「黑匣子」。它不光记录代码，还记录着每一次变更的原因、时间、责任人。嗯，咱们一步步来看。
为什么ADAS需要版本管理？
你想想看，ADAS系统跟普通App最大的区别是什么？是它直接关系到生命安全。我见过太多团队，前期不重视版本管理，到了路测阶段发现某个功能异常，结果谁也说不清是哪个版本引入的问题。
具体来说，ADAS系统对版本管理的需求体现在这几个方面：
- 功能安全合规：ISO 26262要求可追溯性。每个软件变更都要能追溯到需求、设计、测试用例。没有版本管理，你拿什么去追溯？
- 多传感器融合的依赖管理：摄像头、毫米波雷达、激光雷达，每个传感器的算法版本都可能不同。我曾经遇到过一个项目，摄像头算法升级了，但雷达的接口没同步更新，结果融合模块直接崩溃。
- OTA升级的回滚能力：车卖出去之后，OTA升级是常态。如果新版本有问题，必须能快速回滚到上一个稳定版本。没有版本管理，回滚就是一句空话。
- 多团队并行开发：感知团队、规划团队、控制团队，大家都在改代码。没有版本管理，代码冲突能让你怀疑人生。
核心观点：ADAS的版本管理不是「要不要」的问题，而是「怎么做好」的问题。它直接决定了你的系统能不能安全、稳定地交付。
版本号命名规范：语义化版本
版本号怎么定？我见过有人用日期当版本号，比如20250315。也有人用随机数，比如v1.2.3.4.5。这些做法，说白了就是给自己挖坑。
我个人强烈推荐使用语义化版本（Semantic Versioning）。它的格式很简单：主版本号.次版本号.修订号。
举个例子：2.1.3
- 主版本号：做了不兼容的API修改。比如感知算法从传统视觉切换到深度学习，接口全变了。
- 次版本号：新增了向下兼容的功能。比如新增了一个车道保持辅助功能，但原有的功能不受影响。
- 修订号：做了向下兼容的问题修正。比如修复了一个偶发的误刹车bug。
我在项目中遇到过一个问题：某个供应商提供的感知模块，版本号从1.0.0直接跳到2.0.0，我们以为接口全变了，结果发现只是修复了几个小bug。这就是典型的版本号滥用。
避坑指南：我曾经见过一个团队，在版本号后面加了一堆后缀，比如v2.1.3-beta.20250315.hotfix。这种做法虽然信息量大，但可读性极差。我建议预发布版本用-alpha、-beta、-rc就够了，别搞太复杂。
对于ADAS系统，我还会在版本号中额外标注功能安全等级。比如：
v2.1.3-ASIL-B
v3.0.0-ASIL-D这样一看就知道，这个版本通过了哪个安全等级的认证。
版本管理工具选型：Git vs SVN
工具选型，说白了就是选Git还是选SVN。我两个都用过，说说我的感受。
| 特性 | Git | SVN |
|---|---|---|
| 架构 | 分布式 | 集中式 |
| 离线工作 | 支持 | 不支持 |
| 分支管理 | 轻量、灵活 | 较重、目录级 |
| 学习曲线 | 较陡 | 较平缓 |
| 大文件处理 | 需要LFS扩展 | 原生支持较好 |
| 代码审查 | Pull Request流程成熟 | 需要额外工具 |
我个人习惯用Git。为什么？因为ADAS开发中，分支管理太重要了。
举个例子：你正在开发一个新功能，比如自动泊车。同时，路测团队发现了一个紧急bug需要修复。用Git，你可以轻松创建一个feature/auto-parking分支，然后在main分支上修复bug。两个互不干扰。
但SVN也不是一无是处。我记得有一次，一个合作伙伴坚持用SVN，理由是他们的算法模型文件很大（几个GB），Git LFS处理起来太麻烦。嗯，这种情况SVN确实有优势。
注意事项：如果你选择Git，一定要配置好.gitignore。ADAS项目中有大量编译产物、模型文件、日志文件，这些都不应该提交到仓库。我曾经见过一个同事，把整个build目录都提交了，仓库瞬间膨胀到10GB。
最后，我建议团队统一使用Git，并配合Git Flow或Trunk-Based Development工作流。对于ADAS这种需要严格质量控制的系统，我个人更倾向于Git Flow，因为它有明确的develop、release、hotfix分支，流程清晰，责任明确。
好了，版本管理的基础就聊到这里。记住一句话：版本管理不是束缚，而是保护。它保护你的代码，保护你的团队，更保护最终用户的安全。