在 Git strategy 中，主要分為三種 flow: Git flow, Github flow 和 Gitlab flow. 這篇文章主要介紹一下 Gitlab flow, Git flow 的部分可以參考之前的文章: [Git] Git Flow 開發流程.
Upstream First
在 Gitlab flow 中最主要的原則是上游優先 (Upstream first), 也就是只存在一個主分支 master, 它是所有分支的上游，只有通過測試之後才能往下游合併。
Gitlab flow 分成兩種情況，以因應不同的開發流程:
- 持續發布
- 版本發布
持續發布
在持續發布的專案中，建議在 master 分支以外，再多建立不同的環境分支，例如: 開發環境是 master, 預發環境是 pre-production, 生產環境是 production.
在開發時，會從 master 另外建立分支做開發，當開發到一段落後，就會發 pull request (PR) 來 merge to master, 在發 PR 之後，會進行 code review、自動化測試…等等，通過後才可 merge 回 master, 接著再依序往下合併。
而如果在 production 環境中發生 bug, 則要再從 master 建立一個新的分支，修改完成後要先合併到 master, 通過 code review 及測試之後再使用 cherry-pick 依序往 pre-production、 production 分支合併。
版本發布
Gitlab flow 對於版本發布的專案，建議是每一個穩定版本都要從 master 拉出新的分支，例如下圖的 2-3 stable, 2-4 stable. 如果有 bug, 一樣要再建立一個新的分支，修改完後一樣要先合併到最上游的 master, 通過測試之後再合併到版本發布的分支，並且更新版本號。
合併的方式
在發布新的版本或功能時，是從 master 依序往下(pre-production, production) merge，但是不一定所有 master 上的 commit 都要發布，所以在 Gitlab flow 中是採用 git cherry-pick 來挑選需要的 commit 部署到 pre-production 和 production 分支。
如果所有小分支合併回主要分支(master)都是使用 rebase 後進行 fast-forward 的方式合併，那在 master 分支上挑選 commit 的時候，會很容易造成漏挑 commit 的狀況。因此，在 Gitlab flow 中通常會採用 git merge --no-ff 或 git merge --squash 的方式:
git merge --no-ff: 透過--no-ff合併時，會把合併的 branch 的 commit 包在一個圓圈內，因此在cherry-pick時，只要挑選圈內的所有 commit 即可。
git merge --squash: 透過--squash合併時，會把合併的 branch 的所有 commit 壓縮在一個 commit 中，因此在cherry-pick時也不會漏挑。
總結
Gitlab flow 不像 Git flow 那麼複雜，也不需要頻繁的切換分支，感覺起來更適合小型團隊、版本快速迭代的專案。