GitLab flow
採用 upstream first policy,
只有一個主要的分支 "master", 當要開發新功能時, 就是從 master 開一條新的分支出來修改, 最後再透過 Merge Request (MR) 把分支合併回 master
發布時, 針對不同的環境建立不同的分支像是 pre-production 以及 production 分支, 透過 cherry-pick 的方式, 將要發布的內容先從 master 合併到 pre-production 的分支上,
當pre-production 測完沒問題後再做一次 cherry-pick 把這些更動內容從 pre-production 合併到 production 的分支上作正式的發布
簡單的說, 所有的更動都是從 master 開分支出來改, 然後才合併到下游分支中 (master > pre-production > production)
結論
GitLab flow 相較於 Git flow 來說不會太過複雜, 沒有一堆分支需要維護, 即使是新進人員也能夠快速地上手, 而相對於 GitHub flow 來說在軟體發布的方面也比較有彈性, 不會被侷限在主分支 master 上, 因此 GitLab flow 等於是集結了 Git flow 以及 GitHub flow 兩者的優點
留言
張貼留言