討論 Gitlab flow 之 Release (stable) branch 建立與否
前言
現今討論關於 Git 的工作流程，對象不外乎是 Git flow, Github flow & Gitlab flow。這三者變化可以粗略地概括為複雜 → 簡化 → 再補充。
由於團隊使用 Gitlab 作為遠端程式碼儲存庫，考量 GUI 與流程的適性，團隊決議使用 Gitlab flow 進行開發。
關於 Gitlab flow 的精隨官方文件已經點出，掌握「上游優先」是相當重要的，但是在一些細節上，個人認為還有探討的空間。本文想針對 Release (stable) 分支進行一些討論。
討論
我們先看一段原文：
Only in case you need to release software to the outside world you need to work with release branches. In this case, each branch contains a minor version (2–3-stable, 2–4-stable, etc.).The stable branch uses master as a starting point and is created as late as possible. By branching as late as possible you minimize the time you have to apply bugfixes to multiple branches.
有兩個部分引起我的興趣：
- 當要釋出到外界時 (release software to the outside world)。
- 越晚建立越好 (as late as possible)。
網路上有些 Gitlab flow 的說明文章，並沒有在 Release 分支有詳盡的論述，但通常傾向 Release 「一律」要開立 Stable 分支，我想這部分還有探討的空間。我們可以思考對外釋出的支援期程為何？每個版本都 LTS？這會視團隊開發的政策而定；另一方面，如果您的釋出對象是內部，而且迭代速度極快，或許會直接跟進最新的版本，同時享有累積的修正與新功能。
此外，Gitlab flow 定義的 stable 分支鎖定在某個 minor 層級版本，例如 1–2-stable，這意味著後續迭代只會包含必要的 bug fixes。那麼一開始的 1.2.0 這個版本應該發生在哪裡呢？理論上是會在 master 分支上釋出 1.2.0，後續再視需求建立 1–2-stable 以進行持續性的支援，如此才會確保 master 分支上存有版本推進的記錄。
小結
看起來 Release 分支的建立可能不是必要的，得視團隊需求而定。
參考資源
https://docs.gitlab.com/ee/workflow/gitlab_flow.html
https://docs.gitlab.com/ee/university/training/gitlab_flow.html
https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf
