3. 版本管理基础：版本号命名规范（语义化版本）、版本标签与分支策略

在项目进度控制中，版本管理是维护基线稳定性的核心手段。没有规范的版本号、清晰的标签体系和合理的分支策略，基线将形同虚设。本节从三个维度构建版本管理的基础框架。

3.1 语义化版本号命名规范

语义化版本（Semantic Versioning，SemVer）是目前业界最广泛采用的版本号规范。它通过 主版本号.次版本号.修订号 的三段式结构，向使用者传递明确的兼容性信号。

版本段	名称	变更条件	对基线的影响
X	主版本号	不兼容的 API 或重大功能重构	基线必须重建，回退成本最高
Y	次版本号	向下兼容的新功能、新增接口	基线可扩展，回退风险较低
Z	修订号	向下兼容的问题修复、性能优化	基线可原地替换，回退最安全

语义化版本还支持预发布版本号和构建元数据：

• 预发布版本：在修订号后追加连字符和标识符，如 1.0.0-alpha.1、2.3.0-rc.2。预发布版本优先级低于正式版本，不应用于生产基线。
• 构建元数据：在版本号后追加加号和标识符，如 1.0.0+build.20250301。构建元数据不影响版本优先级，仅用于标识构建环境或时间戳。

# 语义化版本示例
1.0.0                    # 初始稳定版本
1.1.0                    # 新增功能，兼容旧版
1.1.1                    # 修复 bug，无新功能
2.0.0-alpha.1            # 重大重构，内部测试
2.0.0-rc.1               # 发布候选，基线冻结前验证
2.0.0+build.20250315     # 正式发布，附带构建信息

3.2 版本标签与基线锚定

在 Git 等版本控制系统中，标签（Tag） 是版本号的物理载体。标签将语义化版本与代码仓库中的特定提交绑定，形成不可变的锚点。基线进度维护依赖标签来实现精确回退和追溯。

标签命名规范建议：

• 正式版本标签：v{主版本}.{次版本}.{修订号}，如 v3.1.0
• 预发布版本标签：v{主版本}.{次版本}.{修订号}-{预发布标识}，如 v3.1.0-beta.1
• 基线快照标签：baseline-{项目代号}-{日期}，如 baseline-pay-20250301

3.3 分支策略与基线隔离

分支策略决定了团队如何并行开发、如何隔离风险、如何将变更合并回基线。不同的项目规模和发布节奏需要匹配不同的分支模型。

以下是三种主流分支策略的对比：

分支策略	核心分支	适用场景	基线维护特点
Git Flow	master、develop、feature、release、hotfix	大型项目、固定发布周期	基线在 master 分支上建立，release 分支用于基线预冻结
GitHub Flow	main、feature	持续交付、小型团队	基线在 main 分支上建立，通过 PR 合并后立即部署
GitLab Flow	main、pre-production、production、feature	多环境部署、需要环境隔离	基线在 production 分支上建立，pre-production 用于基线验证

在进度基线维护中，推荐采用 Git Flow 的简化变体，核心原则如下：

1. 主分支（main/master）：只接受来自 release 分支或 hotfix 分支的合并。每个合并提交必须对应一个基线标签。
2. 开发分支（develop）：日常开发集成分支。所有 feature 分支从此拉出，合并回此分支。
3. 发布分支（release）：从 develop 分支拉出，用于基线冻结前的最终测试和缺陷修复。发布分支上不允许新增功能。
4. 热修复分支（hotfix）：从主分支拉出，用于紧急修复生产基线中的缺陷。修复完成后同时合并回主分支和开发分支。

3.4 基线回退策略与版本恢复

当进度基线出现严重偏差或缺陷时，需要执行回退操作。版本管理为回退提供了三种层次的手段：

• 提交级回退：使用 git revert 撤销特定提交的变更，保留历史记录。适用于小范围、低风险的修复。
• 标签级回退：将当前分支重置到某个基线标签指向的提交，使用 git reset --hard <tag>。适用于需要整体回退到上一个稳定基线的情况。
• 分支级回退：从历史基线标签拉出新的修复分支，修复后重新建立基线。适用于主分支已被污染、无法直接重置的场景。

# 提交级回退（推荐，保留历史）
git revert <commit-hash>
git push origin main

# 标签级回退（谨慎使用，会丢失中间提交）
git reset --hard v1.0.0
git push --force origin main

# 分支级回退（最安全，适合团队协作）
git checkout -b hotfix/rollback-v1.0.0 v1.0.0
# 在 hotfix 分支上修复问题
git commit -m "fix: 回退到 v1.0.0 并修复关键缺陷"
git tag v1.0.1
git push origin v1.0.1