版本控制基础：Git分支策略、语义化版本控制、版本号管理与标签
聊到系统升级回滚，绕不开一个基础问题——版本怎么管？
我见过不少团队，上线前手忙脚乱地翻代码，问「昨天那个稳定版本是哪个commit？」。这种场景，说白了就是版本控制没做好。今天我把这块掰开揉碎了讲，都是实战中踩过的坑。
一、Git分支策略：别让分支变成一团乱麻
分支策略这东西，没有银弹。但我个人习惯用一套相对成熟的模型，叫「Trunk-Based Development」的变体，配合Git Flow的一些理念。
核心原则：主分支永远可部署，功能分支短命且专注。
1. 主分支（main / master）
这是你的「圣杯」。任何时候，main分支上的代码都应该是生产就绪的。我在项目中遇到过有人直接往main上push代码，结果CI挂了三天没人修——嗯，后来我们加了分支保护规则。
2. 开发分支（develop）
日常开发的主战场。所有功能分支从这里拉出去，合并回来。注意，这里不是直接合并，而是通过Pull Request（PR）审核。
3. 功能分支（feature/xxx）
每个新功能一个分支。命名规范我建议用 feature/功能描述-日期，比如 feature/user-login-20250315。为什么加日期？方便回溯，你想想看，三个月后看到一堆feature分支，没日期你根本不知道哪个先哪个后。
4. 发布分支（release/x.y.z）
准备上线时，从develop拉出release分支。这个分支只做bug修复和文档更新，不加新功能。我曾经犯过一个错，在release分支上加了新功能，结果测试全乱套了——从那以后，我严格规定release分支只修bug。
5. 热修复分支（hotfix/x.y.z）
线上出紧急bug时，从main拉出hotfix分支。修完合并回main和develop。注意版本号要递增。
我的建议：小团队用「GitHub Flow」就够了，就一个main分支加功能分支。大项目或者多人协作，才需要完整的Git Flow。别为了流程而流程。
二、语义化版本控制：版本号里藏着信息
版本号不是随便写的。语义化版本控制（SemVer）是目前业界最通用的标准。格式很简单：主版本号.次版本号.修订号。
| 版本号 | 含义 | 举例 |
|---|---|---|
| 主版本号 | 不兼容的API修改 | 1.0.0 → 2.0.0 |
| 次版本号 | 向下兼容的功能新增 | 1.0.0 → 1.1.0 |
| 修订号 | 向下兼容的问题修正 | 1.0.0 → 1.0.1 |
说白了，版本号就是一张「兼容性说明书」。你看到 2.0.0，就知道升级可能要改代码；看到 1.0.5，就知道只是修了几个小bug。
注意：别在版本号里加「beta」「rc」这些后缀，除非你明确知道自己在做什么。生产环境只认纯数字版本号。
三、版本号管理：从开发到上线的全流程
版本号怎么管？我有一套固定的流程，分享给你。
1. 开发阶段
版本号用 0.x.x 或者 1.x.x-SNAPSHOT。比如 1.0.0-SNAPSHOT，表示还在开发中，随时可能变。
2. 发布候选阶段
拉出release分支时，版本号改为 1.0.0-rc.1。如果测试发现问题，修完就变成 1.0.0-rc.2。直到所有问题解决。
3. 正式发布
合并到main后，打上 v1.0.0 标签。这个标签就是你的「黄金版本」。
4. 热修复
从 v1.0.0 拉出hotfix分支，修完打 v1.0.1 标签。
实战经验：我习惯在每次合并到main后，自动触发一个脚本，把版本号写入一个 version.txt 文件。这样部署时直接读文件，不会搞错。
四、标签：给版本打上「锚点」
标签（Tag）是Git里最容易被忽视的功能。说白了，标签就是给某个commit起个名字，方便以后快速找到。
1. 标签命名规范
我建议用 v主版本.次版本.修订号 的格式。比如 v2.3.1。不要用 release-2.3.1 或者 2.3.1-final，保持简洁。
2. 标签类型
- 轻量标签：只是一个指针，不包含额外信息。适合临时标记。
- 附注标签：包含作者、日期、消息。适合正式发布版本。
我个人只用附注标签。为什么？因为你可以写一段话，说明这个版本改了啥。比如：
git tag -a v1.0.0 -m "正式发布v1.0.0，修复了登录超时bug，新增了用户头像上传功能"这样半年后回来看，一眼就知道这个版本干了什么。
3. 标签与回滚的关系
回滚时，标签就是你的「救命稻草」。我曾经遇到一次线上事故，新版本上线后数据库连接池爆了。我直接 git checkout v0.9.8，然后重新部署，5分钟搞定。如果没有标签，你得去翻commit历史，找到那个「好像没问题」的版本——你想想看，那得多慌？
避坑指南：我曾经犯过一个错，打完标签后忘了推送到远程仓库。结果同事部署时找不到标签，只能手动找commit。所以记住：git push origin --tags，打完标签立刻推送。
五、实战：一个完整的版本控制流程
光说不练假把式。我给你走一遍完整的流程。
- 开发新功能：从develop拉出
feature/payment-module，开发完提交PR。 - 准备发布：从develop拉出
release/1.2.0，版本号改为1.2.0-rc.1。 - 测试修复：发现bug，在release分支上修，版本号改为
1.2.0-rc.2。 - 正式发布：合并到main，打标签
v1.2.0，部署上线。 - 热修复：线上出bug，从
v1.2.0拉出hotfix/1.2.1，修完合并回main和develop，打标签v1.2.1。
这套流程我用了好几年，团队从3个人扩展到30个人，一直没出过大问题。说白了，版本控制的核心不是工具，是纪律。你定好规则，大家遵守，回滚就是分分钟的事。
总结一句话：分支策略管流程，语义化版本管兼容性，标签管回溯。三者缺一不可。
下一章我们聊「自动化构建与持续集成」，到时候我会讲讲怎么用CI/CD把版本控制串起来，让机器帮你干活。