Choerodon豬齒魚實踐之持續交付中的分支管理與版本控制

如今愈來愈多的項目使用Git做爲版本控制的工具，經過Git進行分支和Tag管理，大多數狀況這個過程都由手工完成，缺少相應的規範，對於分支和版本號的控制也很隨意，出現這樣的狀況每每是你們對軟件交付過程當中的軟件版本控制不夠重視，「只要確保軟件是最新的版本便可」，甚至是項目管理的漏洞或者缺陷。其實軟件的版本控制以及分支管理貫穿於整個軟件產品的生命週期，平常的項目管理對於開發團隊可否有節奏且順利的交付軟件也很重要。

的確！頻繁的衝突搞的開發人員頭暈腦脹，例如，一次項目在代碼合併時出現了衝突，致使整個項目組挨個排查，花費了大半天的時間，影響開發效率還浪費資源；開發人員隨意建立分支，各類不規範的合併使得Git Graph線條雜亂無章，徹底看不出來主幹發展的脈絡；提交信息混亂，不知道此次提交是由於什麼，實現了什麼功能 ，解決了什麼問題。

本文並非一篇技術文章，其中也沒有讓別人耳目一新的觀點或者論述。本文是爲咱們這些但願進行簡單、有效地協做的人準備的。任何參與到軟件開發的人，不管承擔何種角色，均可能對其感興趣——畢竟每一個人都會用到分支和合並。本文將結合Choerodon豬齒魚爲你們闡述如何進行方便有效的分支管理和版本控制，以及如何選擇適合自身的版本控制模型。

如何來解決這些問題呢？

有經驗的老司機可能會說，「創建規範」。

是的，只有創建規範，才能抑制很差的事情繼續在項目組蔓延。至於創建什麼樣的規範？咱們不妨先制定一個目標。

目標

• 簡單——全部的團隊成員天天都會使用這些模式，因此相關規則和程序必需要簡單明瞭。
• 靈活——可選擇不一樣的分支管理模型，例如GitFlow、GitLabFlow或者GitHubFlow，甚至自定義。
• 可視化——界面化比命令行更安全可控，將分支管理模型的規則和約定固化到系統中。
• 需求與代碼關連——分支須要和具體的任務需求關連。

做爲一個有經驗項目管理者，或者產品負責人，你必定會思考一個問題：咱們項目組在開發過程當中應如何管理分支？不錯，分支管理將和項目組開發人員日夜伴隨，若是採用了一個不合適的分支管理模型，那麼能夠想象兄弟們得多麼的痛苦。

Okay，那麼就從分支管理模型開始......

分支管理規範

GitFlow、GitHubFlow等都是已經被證實頗有效的分支管理模型，可是這些更多的是書面的規則、約定，基本上是靠着程序員的自覺性和Git命令一塊兒維持着這個約定，其實無數的經驗告訴咱們「這很脆弱」。因此，如何使用系統界面化操做將這些規則和約定表示出來，就變得頗有意思。

分支管理模型

不要着急，先來看看 Choerodon 豬齒魚提供的分支模型，Choerodon使用 GitLab 進行分支管理，默認分支爲 master。目前支持七種常見的分支類型：

1. master：主分支，用於版本持續發佈；
2. develop：開發分支，即平常迭代使用的開發分支，用於平常開發持續集成；
3. feature：特性分支，用於平常開發時切出分支進行單功能開發；
4. bugfix：故障修補分支，一般用於修復故障；
5. release：發佈分支，適用於產品發佈、產品迭代；
6. hotfix：熱修分支，用於產品發佈後修復缺陷；
7. custom：自定義分支，用戶能夠自定義須要的分支類型。

注:

1. develop是GitFlow分支模型的重要組成部分。
2. bugfix旨在與敏捷的問題類型（故障）呼應，用於標識此分支的任務是修復某個故障。

這7個分支就是咱們手中的7個魔方，經過這7個魔方的組合能夠變化出無盡的分支管理模型，好比GitHubFlow。

GitHubFlow分支模型只存在一個master主分支，平常開發都合併至master，永遠保持其爲最新的代碼。

• 在領到平常開發任務時，基於master建立feature特性開發分支，提交代碼後，合併至master並刪除feature。
• 在領到修復故障的任務時，基於master建立bugfix故障修補分支，提交代碼後，合併至master並刪除bugfix。
• 須要發佈時，一樣須要基於master建立release，生成的應用版本部署在UAT測試環境進行測試，若須要修改則提交至release。
• 產品上線後發現故障須要緊急進行熱修復時，則基於tag建立hotfix，將修復的代碼提交至hotfix；部署該分支上的版本經過驗收後，基於hotfix打出熱修版本的tag，如0.8.1。
• 因爲新版本的迭代也同時進行，因此須要在hotfix上rebase master，變基至master分支最新的提交，再合併至master並刪除hotfix，就能夠將本次修改的提交應用至master上。

這個分支模型的優點在於簡潔易理解，將master做爲核心的分支，代碼更新持續集成至master上。根據目前收集到的反應來看，獲得了更多的好評，認爲GitHubFlow分支模型更加輕便快捷。

若是GitHubFlow不合適，可使用GitLabFlow或者GitFlow，也能夠自行定義規則。這裏沒有「銀彈」，只是相對比較靈活的配置。

分支命名規約

有了分支管理模型，還須要命名規約，不一樣類型的分支命名方式應該不一樣，值得慶幸的是，豬齒魚已經幫你完成了這個步驟。feature、bugfix分支的分支名使用的是關聯問題的issue號（在豬齒魚中打通了需求和代碼分支的關連關係），對於release及hotfix，分支名可命名爲須要發佈的版本號，如0.8.0、0.8.1等。在這裏使用到了相似0.8.0這樣的版本編號規則，若是你對此不瞭解，沒有關係，在下面將詳細的介紹。

提交命名規約

除了分支的名稱須要規範，提交的命名也一樣如此。不幸，豬齒魚並無把這個規則固化到系統中，須要團隊共同遵照。

格式爲：[操做類型]操做對象名稱，如[ADD]readme，表明增長了readme描述文件。

常見的操做類型有：

• [IMP] 提高改善正在開發或者已經實現的功能
• [FIX] 修正BUG
• [REF] 重構一個功能，對功能重寫
• [ADD] 添加實現新功能
• [REM] 刪除不須要的文件

合併請求

合併請求是開發過程當中必不可少的一個環節，其中有以下一些重要的事情要作：

1. 代碼Review

2. 啓動CI

   • 單元測試
   • 代碼質量檢查

版本號規則

在軟件管理的領域裏存在着被稱做「依賴地獄」的死亡之谷，系統規模越大，加入的套件越多，你就越有可能在將來的某一天發現本身已深陷絕望之中。
                              —— Tom Preston-Werner 的《語義化版本2.0.0》

在這裏咱們不去解讀到底什麼是「依賴地獄」，你們能夠到語義化版本2.0.0中瞭解。那麼，咱們的重點是什麼呢？在這以前，先了解一下「語義化的版本控制」

版本格式：主版本號.次版本號.修訂號，版本號遞增規則以下：

1.主版本號：當你作了不兼容的 API 修改，
2.次版本號：當你作了向下兼容的功能性新增，
3.修訂號：當你作了向下兼容的問題修正。

先行版本號及版本編譯信息能夠加到「主版本號.次版本號.修訂號」的後面，做爲延伸。

這就是「語義化的版本控制」最核心的規則，固然這不是所有，Tom Preston-Werner還詳細的闡述了主版本號、次版本號和修訂號的變化遞增規則，不過這些規則很長，很複雜。

沒有關係，豬齒魚幫咱們作了這些複雜的事情，將「語義化的版本控制」固化到了系統中，簡而言之，

• 當進行代碼打包時，而非發佈新版本

將版本號規則定爲年.月.日-時分秒-分支名。如：2018.7.20-152837-hotfix-0.8.1，這個時間是當前提交時間。當代碼提交到各個分支上時會自動觸發CI，生成版本號規則如上所示。

• 當須要發佈新版本時，例如如0.8.0、0.8.1

  • 主版本號：當作了不兼容的 API 修改或功能強大的升級，能夠將主版本號的數值增長1。
  • 次版本號：當作了向下兼容的功能性新增或是功能上的小迭代，能夠將次版本號的數值增長1。
  • 修訂號：當作了向下兼容的問題修正，但功能上沒有很大的變化，能夠將修訂號的數值增長1。

需求與代碼關連

一直以來，需求通常和系統的功能聯繫在一塊兒，可是與代碼關連卻不常見，若是能將需求和代碼聯繫在一塊兒，奇妙的化學反應就發生了。

「咱們能夠追溯到一個用戶故事對應了哪些分支，哪幾個提交」，
「甚至出現了一些BUG，能夠找到是哪一個分支提交的，當初爲了發佈XXX新的需求」，
「不只如此，咱們經過需求與代碼分支關連，可以查看到哪些需求已經部署到了測試環境，那些需求已經部署到了正式環境」，
「能夠作從業務到代碼的整個鏈條的統計分析...」

...

這一切，豬齒魚已經幫助項目管理者和程序員實現了。在豬齒魚的敏捷管理服務中，能夠經過用戶故事、任務、缺陷等直接一鍵建立分支，而後，你能夠從git checkout -b 開始愉快而又有挑戰的一天。不只如此，也能夠在分支管理中，將現有的分支關連到用戶故事、任務或者缺陷。

總結

回顧一下咱們的目標，簡單、靈活、可視化，以及需求與代碼關連。版本控制一直都是一件提及來容易，作起來難的事情，可是咱們作到了，重要的是豬齒魚將這些特色和規則固化到了DevOps流程中，讓咱們忘記複雜易錯的操做，把精力放到業務開發上。但願咱們的分享可以給你們帶來幫助。