系统版本管理规范：从分支策略到发布流程

本文是一份非常全面和实用的《系统版本管理规范》。它不仅规定了“怎么做”，更解释了“为什么这么做”，能够直接指导研发团队进行高效、协作和高质量的开发工作。

系统版本管理规范 V1.0

1. 引言

1.1 目的
为规范软件系统的版本管理流程，明确分支策略、版本号规则、发布流程及紧急问题处理机制，确保代码仓库的整洁、可追溯性，提高团队协作效率，保障产品交付质量，特制定本规范。

1.2 适用范围
本规范适用于所有研发、测试及运维人员，涉及所有正式发布的软件项目。

1.3 核心原则

• 稳定性： 主分支（如 main）的代码应始终处于可随时发布的稳定状态。
• 可追溯性： 任何一次代码提交、版本发布都必须有据可查。
• 自动化： 版本构建、测试、发布流程应尽可能自动化。
• 协作高效： 分支策略应清晰，减少合并冲突，支持并行开发。

2. 版本号命名规范（Semantic Versioning）

我们采用语义化版本控制（SemVer 2.0.0），格式为：主版本号.次版本号.修订号，例如：2.1.3。

• 主版本号： 当你做了不兼容的 API 修改。
  • 指导意义： 大版本升级，通常意味着有破坏性变更，需要使用者高度关注。
• 次版本号： 当你做了向下兼容的功能性新增。
  • 指导意义： 新功能发布，是向前兼容的，可以安全地升级。
• 修订号： 当你做了向下兼容的问题修正。
  • 指导意义： Bug修复版本，建议所有用户尽快升级。

预发布版本标识（可选）：
在正式版本后追加 - 和标识符，用于标记非稳定版本，供测试使用。

• 2.1.4-alpha.1：内部测试版。
• 2.1.4-beta.1：公开测试版。
• 2.1.4-rc.1：发布候选版，功能已冻结，基本与正式版无异。

3. 分支管理策略（GitFlow简化版）

我们采用一种简化且高效的 GitFlow 策略，包含以下主要分支：