# Outline
一、前言
二、論述
A、待敘項目
# TL;DR
...
# Updated
2019-10-06: 更新標題文章結構
在雙十連假前，此系列文每天的發文時都會以最簡陳述為主，以求在繁忙的日常中，至少能先維持挑戰鐵人賽的進度，並且逐漸拓展思路與系列結構。預期會在國慶連假將本篇文章論述完整。
礙於自身時間安排，很難在遵循原本想要循序漸進的綱要去寫文章，在只剩一小時要趕兩篇文章的情境，只好先將肚子已有的墨水先倒點出來交付了。今天就先不講原理，而來講講原本進一步才要講的分支策略吧！
自從 2010 年，Vincent Driessen 發表了 A successful Git branching model » nvie.com 一文後，只要談到 Git 的協作模式，大家就會想到 Git Flow 一詞，也就是該文所提到的兩種主要分支 master、develop、三個次要分支 feature、release、hotfix 的協作模式。
自此，看到的團隊，多數都是遵循 Git Flow，至少都會看到 master 和 develop 兩個分支，至於那三個短週期分支就有些有、有些沒有。
直到去年，我也是對 Git Flow 十分推崇，甚至每到一個團隊都會不斷的傳教，希望大家也都採用這個分支略。搭配這個策略，也會順便傳教 Pull Request / Merge Request 與 Code Review。
但在今年，為了在團隊內分享 Git 的課程時（也是這系列文會誕生的原因），進一步去研究一下網路上關於分支策略的文章，得到了許多新觀念，在與團隊分享後也發現更適合敏捷團隊的開發模式，於是在這裡先簡單做個分享。
目前耳熟能詳的分支策略除了 Git Flow 外，再來就是以 PR 聞名的 GitHub Flow。接下來就是可能較少人聽聞的 GitLab Flow，遵循的是上游優先原則。最後就更少人聽聞的 Trunk Base Development Flow。
如前面所述 GIt Flow 被多數人遵循著，而 Git Flow 是 Vincent Driessen 那篇文章基於經驗所講述的一個 Git Workflow 模型，本人也無宣稱該模型就叫 Git Flow，這個流程自然也不會是 Git 官方社群發佈的，事實上也不是推薦的、當然也不會是 GitHub 官方推薦的，這是可以先釐清的。
剛接觸 Git Flow 時被其清晰的合作方式所吸引，認為透過這樣的方式對於協作的管理會有幫助，於事就化身為傳教士開始宣傳，但在實務上其實卻很容易遇到很難直接套用在實際情境。原因在於此流程相對複雜，光是教育訓練就不容易讓所有人接受，更遑論要所有人去遵循這個流程。再來是，這麼多種分支本身就很容易造成合併上的困境，更可怕的是這些分支很多都會變成長週期的分支，經過許久才會合併到主線，這合併的成本就更加龐大，光是解衝突就會使許多工程師抓狂、崩潰，這也與 DevOps 主張的持續整合的思維相悖。
Git Flow 這類原本偏向方便管理的分支，或許是比較瀑布流的思維，加上複雜的使用方式，或許已經與當代強調持續整合、交付的文化格格不入。而 GitHub 便提出了一個理念，就是希望針對每天交付產品的情境，希望採用敏捷的方式每天多次解決小問題，而提出了 GitHub Flow。
至於 GitHub Flow 用了這樣的方式去達到他們的目的，而其中又可能有什麼缺點嗎？我們又為什麼想研究更多分支策略呢？請原諒在時間有限的情況下在此打住，我會在日後有時間後將這篇文章補完，敬請期待。
iThome鐵人賽
看影片追技術