一文掌握软件分支管理

TOC

脚步不停，终达卓越！更多优质文章及代码资源详见公众号《开源519》

最近在项目中发现，软件版本管理较为混乱，框架的修改常常牵一发而动全身，严重影响研发效率。为此，结合过往经验及业界成熟的版本管理实践，以 Sparrow (gitee.com/LinuxTaoist...) 项目为例，对常用的版本管理进行总结。

版本管理涵盖以下几个关键方面：

版本号管理: 用类似于 v1.0.0-rc 的格式标识版本，便于快速识别版本用途。
分支管理: 用master/dev/feature-*等命名不同分支，避免不同项目的修改相互干扰。
标签管理: 每个正式版本打上 tag（如 v1.0.0），用于快速回溯和问题定位。
修改备注:
日常提交， commit 按照模板，明确修改的问题；
版本发布时，更新 CHANGELOG，记录重点变更。
合并策略:
合入开发分支 dev 推荐使用merge，确保开发分支保留最完整的修改;
合入主干分支 master推荐使用覆盖，确保主干分支干净稳定。

分支名	说明
master	主版本。永远支持量产能力
Sparrow-dev	开发迭代分支。源自master, 用于所有功能开发的起点。
feature-*	功能分支。源自Sparrow-dev, 用于开发新特性。完成后合并至Sparrow-dev, 并评估是否删除。
Sparrow-*	项目分支。源自Sparrow-dev, 用于立项后的项目开发。完成后合并至Sparrow-dev 和 master, 并评估是否删除。
bugfix-*	修复分支。源自master, 修复量产分支问题,修复后合并至Sparrow-dev和master, 并评估是否删除。

示例:1.3.0-alpha, 路径 version.cmake

scss 复制代码

# 版本信息
set(VERSION_MAJOR 1)
set(VERSION_MINOR 3)
set(VERSION_REVISION 0)
set(VERSION_PRELEASE "alpha")

X: 主版本号。当做了架构上调整或不兼容的 API 修改。
Y: 次版本号。当添加了向下兼容的功能性新增。
Z: 修订号。当做了向下兼容的问题修正。
build: 编译版本号。用于开发阶段编译版本标识,正式发布版本不包含此字段。
- alpha(内部测试版): 初期测试阶段,主要由内部进行功能验证和缺陷排查。
- Beta(公测版): 发布给外部用户试用,收集反馈并改进,准备最终发布的阶段。
- rc (Release Candidate, 候选发布版): Beta 测试后,修复所有已知关键问题的预发布版本,通常非常接近最终产品。
- GA (General Availability, 正式发布版): 完成所有测试,面向公众正式发布的稳定版本,等同于不带任何后缀的版本号。

从功能开发到最终发布, 分支拉取规则如下:

需求分析期 (未立项)
- 从 Sparrow-dev 拉取分支 feature-xxx分支。
- feature-xxx 中 version.cmake 分支次版本号 +1，编译版本号设为alpha (例 1.2.0-rc -> 1.3.0-alpha)。
项目立项（确定分支名Sparrow-Asia）
- 合并feature-xxx 到 Sparrow-dev，删除 feature-xxx。
- 然后从Sparrow-dev 拉取项目分支 Sparrow-Asia。
- Sparrow-Asia 中 version.cmake 版本号不变，编译版本号为 Beta (1.3.0-alpha -> 1.3.0-Beta)。
项目闭环
- merge Sparrow-Asia 分支到 Sparrow-dev 分支。
- 同时将 Sparrow-Asia 分支覆盖到 master 分支，删除 Sparrow-Asia 分支。
- master 分支中 version.cmake 版本号不变，编译版本号为rc (1.3.0-Beta -> 1.3.0-rc)；更新 CHANGELOG；打上tag(例: Tag_v1.3.0)。
紧急修复
- 从 master 拉取分支 bugfix-xxx 分支。
- bugfix-xxx 分支中 version.cmake 修订号 +1，编译版本号设为 alpha (例 1.3.0-rc -> 1.3.1-alpha)。
- 验证完毕后合并至 Sparrow-dev 和 master 分支。
- master 分支中 version.cmake 版本号不变，编译版本号为rc (1.3.0.1-alpha -> 1.3.1-rc)；更新 CHANGELOG；打上tag (例: Tag_v1.3.1)。

初期项目小，版本管理看似不重要，但随着迭代频繁和团队扩大，混乱的版本管理会直接拖慢交付节奏。
业界有很多成熟的实践，但不同项目（如嵌入式、前端、后端）对分支、发布、协同的需求不同，应根据实际情况灵活调整，建立适合团队自身的版本管理规范。
需要注意的是，分支不宜过多，否则会导致维护乏力，反而影响协作效率，这也是部分管理者不愿意多开分支的原因之一。建议长期保留主干 master 和开发分支 dev，其他稳定版本同步至 master，通过标签 tag 进行标记和管理。
打标签并不只是形式，而是标记每一个功能稳定的版本。因此在打标签时，要确保当前软件测试稳定，且提交准确的重点变更备注。