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

# TL;DR
...

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

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

一、論述

昨天大致提到了 GitHub 便提出了一個理念，就是希望針對每天交付產品的情境，希望採用敏捷的方式每天多次解決小問題，而提出了 GitHub Flow。

那 GitHub Flow 又和 Git Flow 有哪些不同呢？最顯著的就是分支種類從 5 種減為 2 種，只剩名為 master 的主線以及用來進行新變動的 feature 分支。

最顯著的好處是整個流程變得很簡單，要進行任何變動就開啟 feature 分支，完成後就合併為 master，合併回 master 後就立即部署，就這樣。比起 Git Flow 來說，既簡單又明確。

在 master 分支的任何進度都是可以部署的（deployable）

實際上的詳細步驟大致如下：

1. 要去變動些什麼，從 master 建立一個有意義名字的分支作為 feature 分支。
2. 在該分支的 local repository 進行 commit，並定期 push 進度到 remote repository 的同名分支。
3. 當你需要回饋或是協助時、亦或是你覺得分支已經可以合併回 master 時，開 pull request。
4. 當有人 review 過並且認可後，就可以將該分支合併回 master。
5. 一旦該分支合併並推送到 master，你應該立即部署。

從這邊會發現 GitHub Flow 如其最初其想應用的「針對每天交付產品的情境」，非常強調在 master 分支的任何進度都是可以部署的（deployable），並且任何程式碼一旦在 master 上，都應該立即部署，保持產品和程式碼進度狀態的一致。

而使用 Pull Request 的方式，也和 GitHub 的功能和文化非常相襯，畢竟GitHub 是一個以開源專案為主的平台，很多專案仰賴世界各地的開發者一起維護、開發。不像我們在公司可以面對面進行 Code Review 或是直接對談，在網路世界的開源專案開發者，就非常仰賴 Pull Request 進行這些事。

而 master 上的程式碼立即部署，也很適合許多專案的情境，開源專案也很多都是某個語言或框架的套件，規模不大卻被很多人使用，版本發佈頻率也很快。以多數專案使用語意化版本號為例，只要有一個錯誤被修正，就更新 Patch 版號，然後部署、發佈到套件庫平台上、只要有新增什麼功能，就更新 Minor 版號，然後部署、發佈到套件庫平台上，以此類推。

聽起來這樣的流程模型非常美好，但是似乎並不是所有專案都適用，光是要讓 master 程式碼直接部署、發佈，就不是所有開發專案、團隊、組織可以接受的。

於是，GitLab 考慮到開發節奏和版本交付的節奏肯定會有差異，提出了另一個協作模型——GitLab Flow，而 GitLab Flow 又是如何解決這個疑慮的呢？就讓我們明天來聊聊吧！

附錄 A、待敘項目

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