iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 27
2
Software Development

用樂高玩轉 GIT 版本控制系列 第 27

Day 27 - GIT 團隊協作 談 流程管理 01 GitFlow

隨著產品或專案越來越壯大,大部分的團隊也會開始思考透過改善團隊的開發流程,提升產品的品質,例如,在原始碼的品質管理上,開始導入單元測試、整合測試、提倡持續整合、持續部署等機制,而這些機制的背後,通常會有一套屬於版本控制系統的流程管理。

接下來的幾篇,主要會以 GIT 目前常見的幾個開發流程:GitFlow、GitHub Flow、GitLab Flow為主要的討論對象,這些流程,不見得是絕對適用所有場合,但都有一些優點可以討論,今天的這篇,首先就以 GitFlow 當開始。

關於 GitFlow 的起源:

第一次知道到 GitFlow 是在網路上,看到有人討論 nvie 所撰寫的「A successful Git branching model」,他提出了一個如下圖的 GIT 流程線圖管理,這個流程圖,區分為 master、develop、feature、release、master等五個常見的分支,今天主要就是以這張圖,用我自己的說法:

Summary

develop 及 master:GitFlow 上一定存在的兩個分支

develop 及 master:GitFlow 上一定存在的兩個分支

在 GitFlow 的流程裡,一定存在兩個主要分支,首先是 master 分支,主要是記錄正式版本的原始碼,當標註版本 tag 也是在 master 分支上。develop 分支,剛開始 develop 分支是來自 master 分支,而後只有在預備要釋出正式版本時,develop 分支上的版本,才會透過後面回提到的 release 流程,合併到 master 分支上。

develop 分支:由 develop 建立,回到 develop 分支

develop 分支:由 develop 建立,回到 develop 分支

所有的新功能特徵,一律由最近的 develop 分支建立新的 feature 分支,而後回到 develop 分支。

feature 分支回到 develop 分支的過程,通常會搭配 Code Review、持續整合(CI)等機制,除了必須要通過人員的 Code Review,也要確認程式碼的測試有通過,才能夠正式合併到 develop 分支上。

在 feature 回 develop 分支的這過程,實務上,也有一些公司會要求,在回到 develop 分支之前,必須先對 origin/develop 作 rebase,才允許回到 develop 分支,這樣產生的線圖會類似如下。相關 git merge 所產生的線圖差異,可以參考 Day 21 所提到的,如何讓線圖更整齊好閱讀。

先對 origin/develop 作 rebase,才允許回到 develop 分支

release 分支:由 develop 建立,合併到 master 及 develop 分支

由 develop 建立,合併到 master 及 develop 分支

在原始碼開發到一定的段落之後,系統預備進行 release 的作業,此時會由 develop 分支上建立 release 分支,之後通常會在 release 分支上進行更完善的原始碼測試、修正預備釋出版本等動作,等到確定可以釋出時,會分別將該 release 版本合併到 master 分支以及建立 release 後的修正,合併回到 develop 分支。

合併動作完成後,也會在 master 分支上建立對應的 release tag。

hotfix 分支:由 master 分支建立,合併回 master 及 develop 分支

hotfix 分支:由 master 分支建立,合併回 master 及 develop 分支

當線上的主要版本出現必須要馬上解決的問題,這時候會透過 hotfix 機制,開始進行修正。首先會基於 master 分支,建立 hotfix 分支,在該分支上進行問題的修正,當修正完畢之後,會將該修正合併到 master 及 develop 分支上。

為什麼需要合併回 develop 分支呢?因為 hotfix 分支,一開始是基於 master 分支所建立的緊急修正,因此合併回 master 很自然,但因為 hotfix 源自master 分支,自然在目前的 develop 分支上也沒有相關的修正,所以也要合回 develop。

合併動作完成後,也會在 master 分支上建立對應的 release tag。

完整版 GitFlow 流程圖概略如下:

完整版 GitFlow 流程圖

總結:

目前 GitFlow 這個流程最常讓人詬病的是,過程有太多的分支需要建立,流程相對複雜,且對於 GIT 使用還不夠熟悉的使用者來說,這樣的流程需要的 GIT 熟悉程度相對的高,相對的容易在使用的過程中造成一些操作錯誤。

參考連結:


上一篇
Day 26 - GIT 狀況題 03 不小心把還沒合併到主分支的分支刪除了,該怎麼辦?
下一篇
Day 28 - GIT 團隊協作 談 流程管理 02 GitHub Flow
系列文
用樂高玩轉 GIT 版本控制30

尚未有邦友留言

立即登入留言