在软件开发的实际场景中,团队往往需要同时推进开发版的新功能迭代和稳定版的线上问题修复,这就需要一套成熟的版本管理实践来支撑,避免两个版本的维护工作互相干扰。

核心分支策略设计
采用多分支并行的方式是实现同时发布开发版和稳定版的基础,常见的分支结构包含以下几类:
- 主干分支(main/master):仅存放稳定可发布的版本代码,对应线上运行的稳定版,禁止直接在主干分支提交代码。
- 开发分支(develop):作为开发版的主分支,所有新功能的开发代码都先合并到该分支,开发版的发布基于该分支进行。
- 发布分支(release):从develop分支拉取,用于开发版的预发布测试,测试通过后合并到main和develop分支。
- 热修复分支(hotfix):从main分支拉取,用于修复稳定版的紧急问题,修复完成后合并到main和develop分支。
语义化版本号规范
清晰的版本号规则能让团队和用户快速区分开发版和稳定版,推荐采用语义化版本规范,版本号格式为主版本号.次版本号.修订号-预发布标识,具体规则如下:
| 版本类型 | 版本号示例 | 说明 |
|---|---|---|
| 稳定版 | 2.1.0 | 主版本号递增代表不兼容的API修改,次版本号递增代表向下兼容的功能新增,修订号递增代表向下兼容的问题修复 |
| 开发版 | 2.2.0-beta.1 | 预发布标识可以用alpha、beta、rc等,标识该版本为开发测试版本,不建议生产环境使用 |
双版本发布流程
稳定版发布流程
当稳定版需要发布新版本或者修复紧急问题时,执行以下步骤:
- 从main分支拉取hotfix分支,命名格式为hotfix/问题描述,例如hotfix/login_error。
- 在hotfix分支完成问题修复,提交代码并通过测试。
- 将hotfix分支合并到main分支,给main分支打上对应的稳定版版本标签,例如v2.1.1。
- 将hotfix分支合并到develop分支,保证开发分支也同步修复了该问题。
开发版发布流程
开发版的新功能迭代和发布按以下流程执行:
- 开发人员从develop分支拉取功能分支,完成新功能开发后合并回develop分支。
- 当develop分支的功能积累到可发布节点时,从develop分支拉取release分支,命名格式为release/版本号,例如release/2.2.0-beta.1。
- 在release分支进行预发布测试,发现的问题直接在release分支修复。
- 测试通过后,将release分支合并到main分支打上开发版标签,同时合并回develop分支同步修改。
代码示例:Git分支操作
以下是基于Git的双版本管理常用操作命令:
# 初始化仓库 git init # 创建develop分支 git checkout -b develop # 从main拉取热修复分支 git checkout main git checkout -b hotfix/fix_cache_error # 修复完成后合并到main和develop git checkout main git merge hotfix/fix_cache_error git tag v2.1.1 git checkout develop git merge hotfix/fix_cache_error # 从develop拉取发布分支 git checkout develop git checkout -b release/2.2.0-beta.1 # 发布分支测试完成后合并 git checkout main git merge release/2.2.0-beta.1 git tag v2.2.0-beta.1 git checkout develop git merge release/2.2.0-beta.1
注意事项
在实际落地过程中,还需要注意以下几点:
- 禁止直接向main分支提交代码,所有修改都必须通过对应分支合并。
- 版本标签必须和对应的提交绑定,方便后续回溯版本代码。
- 定期清理已经合并的过期功能分支和热修复分支,避免分支过多造成管理混乱。
- 开发版的预发布标识要和内部测试节奏对应,明确告知用户版本的稳定性。
合理的版本管理实践需要结合团队的实际规模和迭代节奏调整,核心目标是让开发版和稳定版的维护互不干扰,同时保证版本迭代的可追溯性。