版本管理
版本管理是软件工程的基础设施，通过版本号清晰传达变更程度和兼容性。合理的版本策略让用户和开发者都能理解每个版本的影响，降低升级风险。
语义化版本
语义化版本（Semantic Versioning，SemVer）是业界广泛采用的版本规范，版本号格式为 MAJOR.MINOR.PATCH。
版本号规则
MAJOR（主版本）：不兼容的 API 变更，如 1.5.8 → 2.0.0。
MINOR（次版本）：向后兼容的功能新增，如 1.5.8 → 1.6.0。
PATCH（补丁版本）：向后兼容的问题修复，如 1.5.8 → 1.5.9。
预发布版本
预发布版本号连接连字符和标识符，如 1.0.0-alpha、1.0.0-beta.1、1.0.0-rc.2。
预发布标识符按优先级排列：alpha < beta < rc < stable。
alpha：内部测试版本，功能不完整，可能有严重 Bug。
beta：功能基本完成，需要测试和反馈。
rc（Release Candidate）：发布候选版本，主要修复 Bug，不添加新功能。
构建元数据
构建元数据连接加号，如 1.0.0+20130313144700。
构建元数据不影响版本优先级，可用于区分不同构建。
版本优先级
版本比较时依次比较 MAJOR、MINOR、PATCH，预发布版本低于正式版本。
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-rc < 1.0.0。
变更日志
变更日志（CHANGELOG）是版本管理的必备文档，记录每个版本的变更内容。
变更类型
Added（新增）：新增的功能。
Changed（变更）：现有功能的变更。
Deprecated（废弃）：即将移除的功能。
Removed（移除）：已移除的功能。
Fixed（修复）：修复的问题。
Security（安全）：安全相关的修复。
变更日志格式
# [1.0.0] - 2024-01-01
## Added
- 用户登录功能
- 数据导出功能
## Changed
- 优化首页加载速度
## Deprecated
- 旧版 API 将在 2.0.0 移除
## Fixed
- 修复登录超时问题
- 修复导出文件名编码问题工具支持
conventional-changelog：根据 Git 提交记录自动生成变更日志。
release-drafter：GitHub Action，自动生成和更新 CHANGELOG。
依赖管理
依赖管理是版本管理的重要部分，依赖冲突和版本漂移是常见问题。
依赖版本规则
精确版本：1.2.3，只使用该版本。
范围版本：^1.2.3（兼容 1.x.x）、~1.2.3（兼容 1.2.x）、>=1.2.3（大于等于）。
通配符：1.2.x、1.x、*。
版本锁定
package-lock.json（npm）、yarn.lock（yarn）：锁定精确版本，确保可重复构建。
go.sum（Go）：记录依赖的校验和，确保依赖完整。
Cargo.lock（Rust）：锁定精确版本。
依赖更新策略
自动化更新：使用 Dependabot、Renovate 自动创建依赖更新 PR。
安全更新：安全漏洞相关的依赖更新优先处理。
定期更新：每个迭代安排时间更新依赖，避免落后太多。
测试覆盖：依赖更新后运行测试，确保兼容性。
发布流程
版本规划
版本路线图：规划未来几个版本的大致内容，不承诺具体时间。
里程碑：使用 GitHub Milestone 或 GitLab Milestone 追踪版本进度。
冻结范围：版本发布前冻结功能范围，避免范围蔓延。
发布检查清单
测试通过：所有测试用例通过，包括单元测试、集成测试、端到端测试。
文档更新：更新用户文档、API 文档、变更日志。
性能回归：运行性能测试，确保没有性能退化。
安全扫描：扫描依赖漏洞，确保无已知高危漏洞。
回滚准备：准备好回滚方案，确保发布失败能快速恢复。
发布策略
滚动发布：逐步将新版本发布给用户，先小范围后大范围。
功能开关：通过配置控制新功能，出现问题可快速关闭。
灰度发布：根据用户特征分流，降低风险。
金丝雀发布：先发布给少量用户，观察指标正常后全量发布。
Git 分支管理
Git Flow
Git Flow 是经典的分支管理策略，适合有明确发布周期的项目。
main：主分支，只包含稳定发布版本。
develop：开发分支，集成所有功能开发。
feature：功能分支，从 develop 分支，完成后合并回 develop。
release：发布分支，从 develop 分支，准备发布时使用，完成后合并到 main 和 develop。
hotfix：修复分支，从 main 分支，紧急修复使用，完成后合并到 main 和 develop。
GitHub Flow
GitHub Flow 是简化的分支管理策略，适合持续部署项目。
main：主分支，始终可部署。
feature：功能分支，从 main 分支，通过 PR 合并到 main。
部署：main 分支合并后自动部署到生产环境。
Trunk Based Development
基于主干的开发，所有开发在主分支进行，频繁发布。
短周期：每天多次合并到主分支。
特性开关：使用功能开关控制未完成功能。
持续集成：主分支始终可构建、可部署。
版本回退
版本回退是发布失败后的应急措施，需要快速决策和执行。
回退决策
影响范围：影响多少用户，是否影响核心功能。
严重程度：是否导致数据丢失、安全漏洞、服务不可用。
修复时间：修复问题需要多久，回退是否更快。
回退执行
快速回退：使用蓝绿部署、金丝雀发布时，切换流量即可。
代码回退：Git 回退到上一个版本，重新部署。
数据回退：数据库有变更时，需要考虑数据兼容性。
回退后处理
根因分析：分析发布失败原因，制定改进措施。
修复方案：修复问题后，评估是否重新发布。
文档记录：记录回退原因和过程，避免重复问题。
版本管理是软件工程的基础实践，清晰的版本策略和规范的发布流程能够降低协作成本，提高系统稳定性。