4. 标签与发布：语义化版本控制（SemVer）、如何给固件打标签、发布流程

好，咱们进入一个非常实操的话题——标签与发布。

说实话，很多嵌入式团队在版本管理上吃过亏。我见过不少项目，固件版本号乱得像天书，什么「V2.3_fix_2023_最终版」这种名字，你看着就想摔键盘。更可怕的是，没有规范的发布流程，生产线上烧错了固件，整批货报废。

嗯，这节课我们就来彻底解决这个问题。

4.1 语义化版本控制（SemVer）—— 给固件一个身份证

语义化版本控制，英文叫 SemVer（Semantic Versioning）。说白了，就是用一套统一的规则来定义版本号，让所有人都能一眼看懂这个版本到底改了啥。

标准格式是：主版本号.次版本号.修订号，比如 2.1.3。

• 主版本号：做了不兼容的 API 或功能改动。比如你改了剃须刀的电机控制协议，旧版 App 连不上新固件了，那就得升主版本。
• 次版本号：增加了新功能，但向后兼容。比如你加了个「旅行锁」功能，不影响原有操作，那就升次版本。
• 修订号：做了 bug 修复。比如修复了电量显示不准的问题，只升修订号。

我个人的习惯是，在版本号后面还可以加预发布标识，比如 2.1.0-alpha.1 或 2.1.0-rc.2。alpha 是内部测试版，beta 是公开测试版，rc 是候选发布版。这样团队内部沟通时，一听就知道这个固件能不能量产。

我在项目中遇到过一件事：有个同事为了省事，把 1.2.3 的固件改了改，重新编译后还是叫 1.2.3，结果生产线上烧录了两次不同的固件，出了大问题。从那以后，我要求每次编译都必须自动生成版本号，绝不允许手动改。

4.2 如何给固件打标签 —— Git Tag 实战

版本号定好了，怎么把它和代码关联起来？答案就是 Git 标签（Tag）。

标签就像给代码库里的某个提交贴一个书签。你随时可以回到这个版本，重新编译出完全一样的固件。

Git 标签分两种：

• 轻量标签：只是一个指针，指向某个提交。适合临时标记。
• 附注标签：包含标签名、标签信息、签名等完整信息。我强烈建议用附注标签，因为它记录了谁在什么时候打了这个标签，方便追溯。

打标签的命令很简单：

# 打一个附注标签
git tag -a v2.1.0 -m "Release version 2.1.0: 新增旅行锁功能，修复电量显示bug"

# 推送到远程仓库
git push origin v2.1.0

# 查看所有标签
git tag -l

# 查看某个标签的详细信息
git show v2.1.0

你想想看，如果团队里每个人都按这个规范来，是不是清晰多了？

4.3 发布流程 —— 从代码到固件的最后一公里

好了，版本号有了，标签也打了，接下来就是发布流程。这个流程我建议用自动化工具来跑，比如 Jenkins、GitLab CI 或者 GitHub Actions。手动操作太容易出错了。

我总结了一个标准的发布流程，分五步：

1. 代码冻结：在发布前，所有新功能停止合并，只允许修 bug。这个阶段通常持续 1-3 天。
2. 打候选标签：在冻结后的代码上打 v2.1.0-rc.1 标签，触发自动化构建和测试。
3. 回归测试：自动化测试跑一遍，包括单元测试、集成测试、硬件在环测试。如果有问题，修 bug 后重新打候选标签。
4. 打正式标签：所有测试通过后，打正式标签 v2.1.0，触发生产构建。
5. 发布固件：将构建好的固件文件（通常是 .hex 或 .bin）上传到 OTA 服务器或发给生产部门。

这里有个表格，可以更直观地看每个步骤的输入和输出：

步骤	输入	输出	负责人
1. 代码冻结	开发分支	冻结分支	技术负责人
2. 打候选标签	冻结分支	rc 标签	版本管理员
3. 回归测试	rc 标签	测试报告	测试工程师
4. 打正式标签	测试通过	正式标签	版本管理员
5. 发布固件	正式标签	固件文件	发布工程师

4.4 发布后的收尾工作

固件发布出去，不代表事情就结束了。还有几件事要做：

• 更新 CHANGELOG：把这次发布的改动记录下来，方便以后查阅。我习惯用 keepachangelog.com 的格式。
• 合并回开发分支：如果发布分支是从开发分支拉出来的，记得把修复的 bug 合并回去。
• 通知团队：在群里发个公告，告诉大家新版本发布了，有哪些改动，有什么注意事项。

嗯，到这里，标签与发布的内容就讲完了。说白了，版本管理不是技术问题，是习惯问题。养成好习惯，能省掉无数麻烦。