3、版本管理基础：为什么需要版本管理、语义化版本规范（SemVer）、版本号组成（主版本.次版本.修订号）、版本标签管理

3.1 为什么需要版本管理？—— 一个让我吃过亏的问题

说实话，我刚入行那会儿，对版本管理这事真没太当回事。

那时候做一个小型远程IO模块，固件改来改去，文件名就叫“final”、“final_v2”、“final_真的不改了”。结果呢？有一次客户现场出问题，我愣是搞不清楚现场跑的是哪个版本。最后只能把设备拆回来，用JTAG读Flash里的固件，再反汇编比对——那叫一个痛苦。

所以，版本管理到底解决了什么问题？我总结了三件事：

• 可追溯：出了问题，能快速定位是哪个版本、改了啥、谁改的。
• 可复现：客户说“上次那个版本没问题”，你能准确找到那个版本并重新构建。
• 可沟通：你跟同事说“用v2.1.3”，大家脑子里想的是同一个东西。

3.2 语义化版本规范（SemVer）—— 业界通用的“语言”

你想想看，如果每个人对版本号的理解都不一样，那沟通成本得多高？

语义化版本规范（SemVer）就是来解决这个问题的。它定义了一套规则，让版本号本身就能传递信息。

我个人习惯用这个格式：主版本.次版本.修订号。比如 2.1.3。

3.3 版本号组成：主版本.次版本.修订号

这三个数字各有各的使命，咱们一个一个说。

位置	名称	什么时候增加	举个例子
第一位	主版本	做了不兼容的API修改，或者重大架构变更	1.0.0 → 2.0.0
第二位	次版本	增加了新功能，但向后兼容	1.0.0 → 1.1.0
第三位	修订号	做了Bug修复，功能不变	1.0.0 → 1.0.1

嗯，这里要注意：版本号一旦发布，就不能再改了。如果你发现v1.0.0有个严重bug，修复后应该发布v1.0.1，而不是重新发布v1.0.0。

3.4 版本标签管理 —— Git里的“锚点”

光有版本号还不够，你得在代码仓库里给每个版本打个标签。说白了，就是给某个commit贴个“到此一游”的标记。

我常用的命令是这样的：

# 打标签
git tag -a v2.1.3 -m "Release version 2.1.3: Fixed Modbus CRC bug"

# 推送标签到远程仓库
git push origin v2.1.3

# 查看所有标签
git tag -l

# 切换到某个标签对应的代码
git checkout v2.1.3

标签命名也有讲究。我建议直接用语义化版本号作为标签名，比如 v2.1.3。别用什么 release_final_v2 这种名字，你想想看，三个月后你自己都分不清哪个是哪个。

3.5 版本管理在远程IO模块中的实际应用

拿我最近做的一个项目举例。我们有一个远程IO模块，固件版本是 v3.2.1。

• 主版本3：表示这是第三代硬件平台，协议从Modbus RTU升级到了Modbus TCP
• 次版本2：表示在第三代平台上增加了两个新功能——支持HART协议和板载数据记录
• 修订号1：表示修复了上一个版本中AI通道采样值偶尔跳变的问题

每次发布新固件，我都会在Release Notes里写明：

## v3.2.1 (2024-03-15)
### 修复
- 修复了AI通道在温度超过60°C时采样值跳变的问题
- 修复了Modbus TCP连接数超过4个时响应超时的问题

### 变更
- 优化了看门狗复位后的启动时间，从3秒缩短到1.5秒

下一章，咱们聊聊怎么用Git来管理固件源码，包括分支策略和合并冲突的处理。那也是个让我踩过不少坑的话题。