iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 29
1
Software Development

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

Day 29 - GIT 團隊協作 談 流程管理 03 GitLab Flow

在前兩篇,分別談了 GitFlowGitHub Flow 兩種常見的 GIT 工作流程,使用上,GitFlow 常常被詬病流程太複雜,團隊成員如果對 GIT 的掌握度沒有一定的水平,很可能造成問題;而 GitHub Flow 很簡單,但如果遇到需要拆分多個區域,分作開發、驗證、測試等區域時,按照原本的 Workflow 又無法滿足,或許,就是因為都還有一些問題,因此GitLab 這家公司,提出了所謂的 GitLab Flow,可以說是 GitFlow 與 GitHub Flow 的結合。

GitLab Flow 的原則

upstream first

GitLab Flow 中,只有一個主要分支 master,所有的分支都是由主要分支建立。官方給這個原則取了一個名字,稱為「upstream first」。

當有新的需求需要變更原始碼時,必須從 master 建立分支,而後開始在新建立的分支 add commits,接著透過 MR (在 GitLab Flow 中,Pull Request 在這邊稱為 Merge Request),Code Review 等討論,合併回主要分支。到目前為止,GitLab Flow 與 GitHub Flow 都還是一樣的,一切都由主要分支開始。

不過 GitHub Flow 所有的變更都是回到主要分支,發佈的版本也是在主要分支上,而在 GitLab Flow 上,可以針對發布版本建立發佈 Production 分支,所有要發佈的需求,從主要分支上,透過 git cherry-pick 的機制,部署到 Production 分支上。(什麼是 git cherry-pick 可參見 Day 15 的介紹。)

GitLab Flow 如何解決需要有不同開發環境的問題

如果開發的工作環境除了開發環境、正式環境,在正式環境之前,還不需要經過準正式環境完整驗證後,才正式發佈正式版本,那在 GitLab Flow 怎麼解決這問題?

GitLab Flow

假設開發環境就是主要分支 master,正式分支稱為 production,而準正式分支稱為 pre-production,那麼,在 GitLab Flow 中,會定義如下圖的流程,同樣的,一切都由 master 作為起點,都有預備要發佈的需求時,則透過 git cherry-pick 的機制部署到 pre-production 上,當準正式版本上測試告一段落,則再次透過 git cherry-pick 發佈到正式分支 production 上。

GitLab Flow 發佈的風險

在 GitLab Flow 上,採用 git cherry-pick 的方式部署,如果所有新需求的分支併回主要分支採每次都 rebase 的後進行 fast-forward 的方式合併,那在 master 分支上挑選 commit 的時候,則容易造成漏挑 commit 的狀況。

fast-forward

因此在 GitLab Flow 中怎麼樣合併新需求的分支,就是很重要的問題,在 GitLab Flow 中,通常會採用 git merge --no-ffgit merge --squash 的方式;透過 --no-ff 的方式,每個需求分支在合併回去時,會把該需求對應的 commit 包覆在一個圈圈內,因此 cherry-pick 的時候,僅需要挑選圈內所有的 commit 即可完整挑選;透過 --squash 的方式,則因為每個需求的 commit 都已經被壓縮在一個 commit 裡,因此沒有漏挑的問題。

  • git merge --no-ff
    git merge --no-ff
  • git merge --squash
    git merge --squash

至於其他 GIT 合併線圖如何讓線圖更容易閱讀好整理的內容,整理在 Day 21Day 22 的內容中。

GitLab Flow 的版本發佈方法

而在做 OpenSource 專案時,可能必須要面對同時維護多個穩定版本的情境,如發佈的版本同時存在 2-3-Stable 及 2-4-Stable 等多版本需要進行維護,在 GitLab Flow 中,僅需要從 master 建立新的分支,如發佈 2.3.0 版本時,則從 master 分支建立 2-3-Stable 分支;之後如有需要發佈 2.3.1 小版本 patch,則透過 master 作 git cherry-pick 挑選需要的 commit 到 2-3-Stable 分支上,同樣的 2-4-Stable 也是相同的模式。

release branch

如此的流程,即可滿足同時維護多個版本的需求,又不至於讓流程變得很複雜。

總結:

經歷連三篇,分別介紹了 GitFlow、GitHub Flow以及本篇的 GitLab Flow,介紹這些流程,主要需要了解流程想解決的事情、優缺點,真正在套用流程到開發團隊內部時,還是可以針對團隊內真正的需求做流程上的變動。

像有些公司會透過發佈流程,在做 PR/MR 前,必須確保原始碼都符合內部定義的 Coding Guideline 因此還會透過 Git Hook 機制或 CI 工具綁定格式測試,也有些公司內部定義 Code Review 必須通過至少兩個人同意。

流程沒有絕對,只有適合自己團隊的流程,才是好流程。

參考資料:


上一篇
Day 28 - GIT 團隊協作 談 流程管理 02 GitHub Flow
下一篇
Day 30 - GIT 團隊協作 談 除了流程外的一些使用原則
系列文
用樂高玩轉 GIT 版本控制30

尚未有邦友留言

立即登入留言