一文掌握软件分支管理

[TOC]

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

引言

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

概要

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

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

分支管理方案

分支命名规则

版本号规则: X.Y.Z-[build]

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

# 版本信息
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 进行标记和管理。
• 打标签并不只是形式，而是标记每一个功能稳定的版本。因此在打标签时，要确保当前软件测试稳定，且提交准确的重点变更备注。