# Outline
一、論述
A、待敘項目

# TL;DR
...

# Updated
2019-10-06: 更新標題文章結構

在雙十連假前，此系列文每天的發文時都會以最簡陳述為主，以求在繁忙的日常中，至少能先維持挑戰鐵人賽的進度，並且逐漸拓展思路與系列結構。預期會在國慶連假將本篇文章論述完整。

一、論述

昨天提到 GitLab 考慮到開發節奏和版本交付的節奏肯定會有差異，提出了另一個協作模型——GitLab Flow。

GitLab Flow 的核心原則就是「上游優先原則（upstream first）」，意即長期分支都有上下游關係，所有變動都必須先被上游分支接受，才能被套用在下游分支。

在 GitLab Flow 中，除了 GitHub Flow 既有的 master 分支（長期）、和 feature 分支（短期）外，會再依照各個部署環境多 1 到多個長期分支，以常聽到的案例為例，多數部署環境都會分為 Staging、User Acceptance Testing (UAT)、Production 三種，所以對應下來就會如下：

• master -> Staging
• uat -> User Acceptance Testing
• production -> Production

只要 master 有任何變動，都會部署到 Staging 環境，這通常是在開發階段。

而任何變動都必須先合併到 master 分支，才能透過將 master 合併到 uat 分支去套用，並且部署 UAT 環境，然後給負責人、客戶或是使用者驗收。

在驗收完後，再將 uat 分支合併到 production 分支，並且部署到 Production 環境。

所以 master 就是 uat 的上游、uat 就是 production 的上游，任何變動都必須先經過上游，才可以流向下游。這就是上游優先原則。

如此就可以解決昨天所述，master 上的程式碼不一定能馬上部署 production 環境的問題。

附錄 A、待敘項目

• GitLab Flow 相關參考圖片
• GitLab Flow 分支線圖
• GitLab Flow 實驗與範例程式碼