掌握高效版本管理：從混亂到有序的蛻變之路

[TOC]

引言

? 最近在項(xiàng)目中發(fā)現(xiàn)，軟件版本管理較為混亂，框架的修改常常牽一發(fā)而動(dòng)全身，嚴(yán)重影響研發(fā)效率。為此，結(jié)合過(guò)往經(jīng)驗(yàn)及業(yè)界成熟的版本管理實(shí)踐，以 Sparrow (https://gitee.com/LinuxTaoist/Sparrow) 項(xiàng)目為例，對(duì)常用的版本管理進(jìn)行總結(jié)。

概要

版本管理涵蓋以下幾個(gè)關(guān)鍵方面：

• 版本號(hào)管理: 用類(lèi)似于 v1.0.0-rc 的格式標(biāo)識(shí)版本，便于快速識(shí)別版本用途。
• 分支管理: 用master/dev/feature-*等命名不同分支，避免不同項(xiàng)目的修改相互干擾。
• 標(biāo)簽管理: 每個(gè)正式版本打上 tag（如 v1.0.0），用于快速回溯和問(wèn)題定位。
• 修改備注:
  日常提交， commit 按照模板，明確修改的問(wèn)題；
  版本發(fā)布時(shí)，更新 CHANGELOG，記錄重點(diǎn)變更。
• 合并策略:
  合入開(kāi)發(fā)分支 dev 推薦使用merge，確保開(kāi)發(fā)分支保留最完整的修改;
  合入主干分支 master推薦使用覆蓋，確保主干分支干凈穩(wěn)定。

分支管理方案

分支命名規(guī)則

版本號(hào)規(guī)則: 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: 主版本號(hào)。當(dāng)做了架構(gòu)上調(diào)整或不兼容的 API 修改。
• Y: 次版本號(hào)。當(dāng)添加了向下兼容的功能性新增。
• Z: 修訂號(hào)。當(dāng)做了向下兼容的問(wèn)題修正。
• build: 編譯版本號(hào)。用于開(kāi)發(fā)階段編譯版本標(biāo)識(shí),正式發(fā)布版本不包含此字段。
  • alpha(內(nèi)部測(cè)試版): 初期測(cè)試階段,主要由內(nèi)部進(jìn)行功能驗(yàn)證和缺陷排查。
  • Beta(公測(cè)版): 發(fā)布給外部用戶(hù)試用,收集反饋并改進(jìn),準(zhǔn)備最終發(fā)布的階段。
  • rc (Release Candidate, 候選發(fā)布版): Beta 測(cè)試后,修復(fù)所有已知關(guān)鍵問(wèn)題的預(yù)發(fā)布版本,通常非常接近最終產(chǎn)品。
  • GA (General Availability, 正式發(fā)布版): 完成所有測(cè)試,面向公眾正式發(fā)布的穩(wěn)定版本,等同于不帶任何后綴的版本號(hào)。

分支拉取規(guī)則

從功能開(kāi)發(fā)到最終發(fā)布, 分支拉取規(guī)則如下:

• 需求分析期 (未立項(xiàng))
  • 從 Sparrow-dev 拉取分支 feature-xxx分支。
  • feature-xxx 中 version.cmake 分支次版本號(hào) +1，編譯版本號(hào)設(shè)為alpha (例 1.2.0-rc -> 1.3.0-alpha)。
• 項(xiàng)目立項(xiàng) （確定分支名Sparrow-Asia）
  • 合并feature-xxx 到 Sparrow-dev， 刪除 feature-xxx。
  • 然后從Sparrow-dev 拉取項(xiàng)目分支 Sparrow-Asia。
  • Sparrow-Asia 中 version.cmake 版本號(hào)不變，編譯版本號(hào)為 Beta (1.3.0-alpha -> 1.3.0-Beta)。
• 項(xiàng)目閉環(huán)
  • merge Sparrow-Asia 分支到 Sparrow-dev 分支。
  • 同時(shí)將 Sparrow-Asia 分支覆蓋到 master 分支，刪除 Sparrow-Asia 分支。
  • master 分支中 version.cmake 版本號(hào)不變，編譯版本號(hào)為rc (1.3.0-Beta -> 1.3.0-rc)；更新 CHANGELOG；打上tag(例: Tag_v1.3.0)。
• 緊急修復(fù)
  • 從 master 拉取分支 bugfix-xxx 分支。
  • bugfix-xxx 分支中 version.cmake 修訂號(hào) +1，編譯版本號(hào)設(shè)為 alpha (例 1.3.0-rc -> 1.3.1-alpha)。
  • 驗(yàn)證完畢后合并至 Sparrow-dev 和 master 分支。
  • master 分支中 version.cmake 版本號(hào)不變，編譯版本號(hào)為rc (1.3.0.1-alpha -> 1.3.1-rc)；更新 CHANGELOG；打上tag (例: Tag_v1.3.1)。

標(biāo)準(zhǔn)流程 (圖示)

版本管理.jpg

總結(jié)

• 初期項(xiàng)目小，版本管理看似不重要，但隨著迭代頻繁和團(tuán)隊(duì)擴(kuò)大，混亂的版本管理會(huì)直接拖慢交付節(jié)奏。
• 業(yè)界有很多成熟的實(shí)踐，但不同項(xiàng)目（如嵌入式、前端、后端）對(duì)分支、發(fā)布、協(xié)同的需求不同，應(yīng)根據(jù)實(shí)際情況靈活調(diào)整，建立適合團(tuán)隊(duì)自身的版本管理規(guī)范。
• 需要注意的是，分支不宜過(guò)多，否則會(huì)導(dǎo)致維護(hù)乏力，反而影響協(xié)作效率，這也是部分管理者不愿意多開(kāi)分支的原因之一。建議長(zhǎng)期保留主干 master 和開(kāi)發(fā)分支 dev，其他穩(wěn)定版本同步至 master，通過(guò)標(biāo)簽 tag 進(jìn)行標(biāo)記和管理。
• 打標(biāo)簽并不只是形式，而是標(biāo)記每一個(gè)功能穩(wěn)定的版本。因此在打標(biāo)簽時(shí)，要確保當(dāng)前軟件測(cè)試穩(wěn)定，且提交準(zhǔn)確的重點(diǎn)變更備注。