2. 版本管理基础概念：Git与SVN对比、分支策略选择、标签管理规范

好，咱们进入正题。安全气囊系统的软件版本管理，说白了就是给代码上“户口”。你想想看，一个气囊ECU里可能有几十万行代码，涉及碰撞算法、点火逻辑、诊断服务……要是版本乱成一锅粥，出了问题你连哪个版本在车上跑着都不知道，那可就真成“气囊”了——气死人的囊。

我个人习惯把版本管理分成三个层次：工具选型、分支策略、标签规范。咱们一个一个聊。

2.1 Git vs SVN：选哪个？

先说说工具。SVN和Git，我估计大家都听过。但到底选哪个？

我在项目中遇到过一家供应商，他们用SVN管了七八年的气囊代码。后来项目规模大了，全球团队协作，SVN那套集中式管理就扛不住了——分支合并慢得像蜗牛，离线就没法干活。最后硬着头皮迁到了Git。

这里我直接给结论：新项目，无脑选Git。为什么？

对比项	Git	SVN
架构	分布式，本地有完整仓库	集中式，依赖中央服务器
分支操作	轻量级，秒级创建/切换	重量级，分支本质是目录拷贝
离线工作	完全支持	基本不行
合并能力	智能三路合并，冲突处理强	合并较笨，容易出问题
学习曲线	稍陡，概念多	简单，容易上手

嗯，这里要注意：SVN也不是一无是处。如果你团队只有三五个人，项目结构简单，SVN的“所见即所得”反而更省心。但安全气囊系统这种高安全等级、多版本并行的项目，Git的分布式优势是碾压级的。

2.2 分支策略选择：别让分支变成“分支地狱”

工具选好了，接下来是分支策略。很多团队一上来就搞Git Flow，结果分支多得像蜘蛛网，合并一次要半天。我个人习惯，根据项目特点选策略。

安全气囊系统开发，我推荐两种主流策略：

2.2.1 主干开发 + 特性分支（Trunk-Based Development）

说白了就是：所有人往主干上合，但每个功能在独立分支上开发。适合持续集成、快速迭代的场景。

• 优点： 冲突少，集成快，适合CI/CD
• 缺点： 对代码质量要求高，合入前必须通过所有测试
• 适用场景： 算法开发、平台软件迭代

2.2.2 Git Flow（经典分支模型）

这个大家可能更熟悉。有master、develop、feature、release、hotfix五类分支。适合需要严格版本管理的产品。

• 优点： 版本隔离好，发布流程清晰
• 缺点： 分支多，管理成本高
• 适用场景： 量产项目、多版本并行维护

我曾经在一个气囊项目中吃过亏。当时我们用了Git Flow，但release分支和hotfix分支没管好，导致一个紧急补丁打到了错误的基线版本上。嗯，从那以后我定了个规矩：hotfix必须从master拉，修完必须同时合入develop和master，少一步都不行。

2.3 标签管理规范：给版本打上“身份证”

分支管好了，标签就是最后的防线。标签说白了就是给某个提交打一个固定的名字，比如“v1.2.3”。这个在安全气囊系统里特别重要——你总得知道哪个版本通过了碰撞测试，哪个版本已经装车了吧？

我建议的标签命名规范：

v<主版本>.<次版本>.<修订号>[-<预发布标识>]

示例：
v1.0.0          # 首次量产版本
v1.1.0          # 新增功能版本
v1.1.1          # 缺陷修复版本
v2.0.0-rc.1     # 候选发布版本
v2.0.0-beta.2   # 测试版本

这里有几个要点：

• 主版本： 架构变更、接口不兼容时增加
• 次版本： 新增功能，向下兼容
• 修订号： 缺陷修复，功能不变
• 预发布标识： alpha、beta、rc，用于内部测试

我个人习惯，每次发布前都要做两件事：

1. 在master分支上打标签，标签名必须和发布文档一致
2. 把标签推送到远程仓库，确保所有人能看到

你想想看，如果有一天客户投诉气囊误爆，你需要回溯代码。没有规范的标签，你连当时用的是哪个版本都查不到，那可就麻烦了。所以，标签管理不是小事，是安全气囊系统版本管理的最后一道保险。

好了，这一章就聊到这儿。下一章咱们讲讲具体的版本号命名规范和变更管理流程，那才是真正落地的东西。