Gitlab flow

我們熟悉的流程...

git flow

Pros:

1. 清晰可控、多種不同功能的 branch

Cons:

1. 相對複雜 (需要專門的 helper script)*

2. 不適用於持續發佈的專案

* 註一 http://danielkummer.github.io/git-flow-cheatsheet/

github flow

github flow

Pros:

簡單、適用於持續發佈

Cons:

很多情況下合併到 master 不代表馬上就能發佈，像是 iOS App 審核，若團隊有 deploy 的窗口，就會導致發佈的程式碼與 master 的程式碼不一致

github flow

gitlab flow

在持續發佈的專案裡，production 和 pre-production 分別是指 production 和 staging 環境

gitlab flow

1. Upstrem first (上游優先)

2. Master 為 pre-production 和 production 的上游

3. 所有的變化需要先 merge 到 master，才能被下游採用

在持續發佈的專案裡，production 和 pre-production 分別是指 production 和 staging 環境

gitlab flow

Hotfix 處理方式：

1. 開 feature branch

2. merge master

3. cherry-pick 到下游分支

好處是這樣你不會忘記要把 hot fix commits 放入 master，避免未來其他下游分支出現同樣 bug

gitlab flow

Example: Chromium project

主旨是避免 kernel version fragmentation

最上游為 Linus Torvalds 的分支

往下為子系統的分支

最後為設備廠商(Samsung, ASUS) 的分支

gitlab flow

針對版本發佈的專案