3. 版本控制与基线管理：Git标签与分支策略、基线的定义与维护、版本号规范（SemVer）
聊到回滚保护，很多人第一反应是“备份”。但说实话，备份只是最底层的保命手段。真正让回滚变得可控、可预期、可自动化的，是版本控制与基线管理。没有清晰的版本号，没有稳定的基线，你连回滚到哪都不知道，更别提什么保护机制了。
这一章，我带你梳理一下我在生产环境中沉淀下来的版本控制实践。核心就三块：Git 分支与标签怎么用、基线到底是什么、版本号怎么定才不乱。
3.1 Git 标签与分支策略
先说说分支策略。我见过不少团队，分支拉得飞起，但合并时一团乱麻。回滚的时候更是灾难——根本不知道哪个分支对应哪个版本。
我个人习惯用 Trunk-Based Development 配合 Git Flow 的简化版。说白了，主干分支只做一件事：保持可发布状态。
核心原则：主干分支（main/master）永远只接受经过验证的合并。任何未经测试的代码，都不允许直接推到主干。
具体来说，我推荐这样划分分支：
| 分支类型 | 命名示例 | 用途 | 生命周期 |
|---|---|---|---|
| 主干分支 | main / master |
生产就绪代码，只接受合并请求 | 永久 |
| 开发分支 | develop |
日常集成，功能分支合并到这里 | 永久 |
| 功能分支 | feature/xxx |
新功能开发，从 develop 拉出 | 开发完成后删除 |
| 发布分支 | release/1.2.0 |
从 develop 拉出，只做 bug 修复和文档更新 | 发布合并到 main 和 develop 后删除 |
| 热修复分支 | hotfix/1.2.1 |
从 main 拉出，紧急修复生产问题 | 修复合并到 main 和 develop 后删除 |
嗯，这里要注意：标签（Tag）才是回滚的真正锚点。分支是流动的，今天指向 commit A，明天可能就指向 commit B 了。但标签是固定的，一旦打上，就永远指向同一个 commit。
我的习惯：每次发布到生产环境，必须打一个带版本号的标签。比如 v1.2.0。这样回滚时，直接 git checkout v1.2.0 就能拿到当时的代码状态，干净利落。
我曾经遇到过一个事故：某团队回滚时用了分支名，结果分支已经被后续合并推进了，回滚到的根本不是他们想要的那个版本。从那以后，我强制要求所有回滚操作必须基于标签，而不是分支。
3.2 基线（Baseline）的定义与维护
基线这个词，不同领域理解不一样。在运维和发布领域，我把它定义为：一个经过验证、可重复、被冻结的软件配置快照。
说白了，基线就是“这一刻，所有东西都是确定的”。代码版本确定了，配置文件确定了，依赖库版本确定了，甚至构建环境也确定了。
为什么基线对回滚这么重要？你想想看，如果回滚时只回滚了代码，但配置文件还是新版本的，那很可能跑不起来。或者依赖库版本变了，行为不一致。基线就是用来避免这种“回滚一半”的尴尬。
避坑指南：我曾经见过一个项目，回滚代码后忘了回滚数据库迁移脚本，结果新版本的数据库字段在旧代码里根本不存在，直接 500 错误。所以基线必须包含 代码 + 配置 + 数据迁移 + 依赖清单 四件套。
维护基线，我建议这样做：
- 每次发布打基线：在 CI/CD 流水线中，发布成功后自动生成一个基线记录。
- 基线内容要完整：至少包含 Git commit SHA、构建产物哈希、配置文件版本、数据库迁移版本号。
- 基线要可追溯：把基线信息写入发布工单或 CMDB，方便事后审计。
- 定期清理旧基线：保留最近 N 个版本即可，太老的基线反而增加管理成本。
下面这张图，是我常用的基线管理流程，你可以参考一下：
3.3 版本号规范（SemVer）
版本号这东西，看似简单，但用不好真的会出大问题。我见过有人用 v1.0、v1.0.1、v1.0.1-hotfix 这种混乱的命名，回滚时根本分不清哪个是最新的。
我强烈推荐使用 语义化版本控制（SemVer）。格式很简单：主版本号.次版本号.修订号，比如 1.2.3。
规则也很清晰：
- 主版本号：做了不兼容的 API 修改时递增。说白了，就是“这次升级，你可能需要改代码”。
- 次版本号：新增了功能，但向后兼容。你可以放心升级，不会破坏现有功能。
- 修订号：做了向后兼容的 bug 修复。这是最安全的升级，通常只改内部实现，不改接口。
一个重要的原则：版本号一旦发布，就不能再修改。如果发现打错了标签，正确的做法是打一个新版本，而不是覆盖旧的。覆盖标签在 Git 里虽然可以做，但会导致分布式环境下的混乱——别人可能已经基于旧标签做了依赖。
除了标准的三段式，我还会在预发布版本上加上后缀：
| 后缀 | 示例 | 含义 |
|---|---|---|
-alpha |
1.2.0-alpha.1 |
内部测试版，功能可能不全 |
-beta |
1.2.0-beta.2 |
公开测试版，功能完整但可能有 bug |
-rc |
1.2.0-rc.3 |
发布候选版，如果没问题就直接转正式版 |
这里有个小技巧：预发布版本的优先级低于正式版本。比如 1.2.0-rc.1 的优先级低于 1.2.0。这在依赖管理工具里很重要，能避免自动升级到不稳定的版本。
我的实践：在 CI/CD 流水线中，我会自动根据分支类型生成版本号。比如 develop 分支的构建自动带上 -alpha 后缀，release 分支带上 -rc 后缀，只有合并到 main 并打标签时才生成正式版本号。这样从版本号上就能一眼看出代码处于什么阶段。
最后说一句：版本号规范不是写出来就完事了，得让整个团队都遵守。我建议把 SemVer 规范写进团队的 CONTRIBUTING.md 里，并且在 CI 流水线中做校验——不符合规范的版本号直接拒绝构建。嗯，强制手段有时候比自觉更管用。