4、标签与发布：语义化版本号（SemVer）规范、如何打标签、发布流程
版本管理这件事，说白了就是给软件一个「身份证」。你想想看，一个理疗仪固件，今天改了个参数，明天修了个bug，后天加了新功能。如果没有清晰的版本号，现场工程师问你「这个版本能不能用」，你只能一脸懵。
我个人习惯，版本号就是项目的「语言」。它告诉所有人：这个版本改了啥，能不能直接升级，会不会破坏兼容性。今天我们就聊聊这个。
4.1 语义化版本号（SemVer）规范
语义化版本号，英文叫 SemVer。它的格式很简单：主版本号.次版本号.修订号。比如 1.3.2。
每个数字都有明确含义：
- 主版本号：做了不兼容的API修改。比如换了通信协议，旧版上位机连不上。
- 次版本号：新增了功能，但向下兼容。比如加了个新的理疗模式。
- 修订号：只做了bug修复。比如修正了某个参数溢出问题。
我在项目中遇到过一件事。有个同事把次版本号当修订号用，结果现场升级后，新功能没生效，老功能还出了问题。为什么？因为次版本号变了，意味着「新增功能」，但测试只按修订号级别做了回归。嗯，这里要注意：版本号不是随便写的，它决定了测试范围。
核心原则：版本号一旦发布，就不能再修改。如果发现打错了，只能发布一个新版本。
除了数字，SemVer 还支持预发布版本号和构建元数据。比如 1.0.0-alpha.1、2.0.0-beta+20231001。预发布版本用于内部测试，优先级低于正式版本。
| 版本号 | 含义 | 示例场景 |
|---|---|---|
| 1.0.0 | 第一个稳定版本 | 理疗仪首次量产 |
| 1.1.0 | 新增功能，向下兼容 | 增加脉冲模式 |
| 1.1.1 | 修复bug | 修正温度显示异常 |
| 2.0.0 | 不兼容的重大变更 | 更换通信协议 |
| 1.2.0-beta.1 | 内部测试版本 | 新功能验证 |
我的建议：嵌入式项目，主版本号不要轻易变。一旦变了，意味着所有配套软件、上位机、产测工具都要跟着改。成本很高。
4.2 如何打标签
标签（Tag）是 Git 里给某个提交打上的「快照」。它和分支不同。分支会移动，标签是固定的。我习惯把标签理解为「里程碑」。
打标签有两种方式：
- 轻量标签：只是一个指针，指向某个提交。适合临时标记。
- 附注标签：包含作者、日期、备注信息。适合正式发布。
我个人只用附注标签。为什么？因为信息完整。你想想看，半年后回来看一个标签，如果只有版本号，你根本不知道当时为什么发这个版本。
打标签的命令很简单：
# 创建附注标签
git tag -a v1.2.0 -m "Release version 1.2.0: 新增低频理疗模式"
# 查看所有标签
git tag -l
# 查看标签详细信息
git show v1.2.0
# 推送标签到远程仓库
git push origin v1.2.0
# 推送所有标签
git push origin --tags我曾经犯过一个错。打标签时忘了加 -a 参数，结果打了一个轻量标签。后来需要回退到这个版本，发现没有任何备注信息，根本不知道这个版本对应哪个需求。嗯，从那以后，我要求团队所有正式发布必须用附注标签。
避坑指南：标签一旦推送，就不要删除。如果删除了，其他开发者的本地仓库会混乱。我曾经因为删除远程标签，导致同事的 CI 构建全部失败。教训深刻。
标签的命名规范，我建议和版本号保持一致。比如 v1.2.0、v2.0.0-beta.1。这样一看就知道对应哪个版本。
4.3 发布流程
发布不是「打个标签就完事」。它是一个流程。我见过太多团队，发布就是「代码合并，打个标签，然后扔给测试」。结果呢？现场出问题，找不到对应版本，回退也回退不了。
一个规范的发布流程，至少包含这几步：
- 代码冻结：在发布分支上，停止新功能开发，只修bug。
- 版本号确认：根据变更内容，确定主版本号、次版本号、修订号。
- 更新版本文件：修改代码中的版本宏定义或配置文件。
- 创建发布分支：从 develop 分支创建 release 分支。
- 打标签：在 release 分支上打附注标签。
- 构建与测试：用标签构建固件，进行完整测试。
- 发布：将标签推送到远程，生成发布说明。
- 合并回主分支：将 release 分支合并到 main 和 develop。
我举个例子。假设我们要发布 v1.2.0：
# 1. 从 develop 创建 release 分支
git checkout -b release/v1.2.0 develop
# 2. 更新版本文件
# 修改 version.h 中的 VERSION_MAJOR、VERSION_MINOR、VERSION_PATCH
# 3. 提交版本更新
git add version.h
git commit -m "Bump version to 1.2.0"
# 4. 打标签
git tag -a v1.2.0 -m "Release v1.2.0: 新增低频理疗模式，修复温度显示bug"
# 5. 构建固件（假设有构建脚本）
./build.sh v1.2.0
# 6. 测试通过后，合并到 main
git checkout main
git merge release/v1.2.0
# 7. 合并回 develop
git checkout develop
git merge release/v1.2.0
# 8. 删除 release 分支
git branch -d release/v1.2.0
# 9. 推送标签和分支
git push origin main
git push origin develop
git push origin v1.2.0关键点：发布分支上的提交，只做版本号修改和bug修复。不要在这里做新功能开发。否则合并时会冲突不断。
发布说明怎么写？我建议包含这几项：
- 版本号与发布日期
- 新增功能列表
- 修复的bug列表
- 已知问题
- 升级注意事项（比如是否需要重新校准）
我曾经见过一个发布说明，只写了「修复若干bug」。现场工程师看到后，根本不敢升级。为什么？因为不知道「若干」是哪些，会不会引入新问题。所以，发布说明要具体。
我的习惯：发布说明用 Markdown 写，和标签一起保存。这样 Git 仓库本身就是完整的发布历史。不需要额外维护一个文档。
最后说一句。版本管理不是束缚，是保护。它保护你、保护团队、保护现场。一个规范的发布流程，能让你的理疗仪固件在成千上万的设备上稳定运行。嗯，这就是我今天想分享的。