# Outline
一、特徵分支不宜久存
二、讓 Git 專心做好自己版本控制的角色
三、只存在一個主線就好
A、待敘項目

# TL;DR
...

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

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

經過這幾天談論 Git 分支策略後，今天就來做個總結吧！

一、特徵分支不宜久存

隨著近年精實文化的概念在軟體工程逐漸成為主流，程式碼在製品的概念也開始被人所討論，一個長期沒有被合併回主線的分支，就是一種在製品，沒有辦法得到任何價值與回饋，是一種浪費。所以從精實的角度而言，一個作出變動的特徵分支，應該要盡快並回主線，且提供一個完整、獨立的功能，儘管再小都沒關係。

而從 Git 的角度而言，隨著分支從主線分岔越久，成本與風險就越高。成本來自於合併回主線的難度會隨著差異越大而提高，甚至這個分支變動的程式碼區塊也在主線有了變化，合併回去就會必須處理越來越多程式碼衝突的問題。就算時常對主線進行 rebase，每一次次的 rebase 出現衝突時，仍然是成本，只是被切得比較小塊而已。另外該分支可以共用的程式碼，因為遲遲沒有變回主線，可能也會導致有其他人也實做同樣的部分，這就是一個重複的成本。

所以在 Git 分支不該存活太久，應該訂個最晚合併的時間，比如說有在跑迭代開發，就是該週期結束前一定要合併回去。最好的做法，是分支在每天下班前就合併回去，這會讓我們省思如何去拆分一次變動，讓他夠小且有意義。

二、讓 Git 專心做好自己版本控制的角色

在 Modern Web 2019 裡，有去聽高見龍大大的演講，並在議程後得講者面對面中旁聽他與其他會眾的對話，有一個概念讓我印象很深刻，那就是很多時候會眾詢問的問題，其實都不是 Git 該處理的問題，而是軟體架構面該處理的問題，但我們卻想強求 Git 去處理，自然就會冒出許多想不出解法的處境。

例如我們可能會想使用分支作為 namespace 的功能，去幫我們將確定要釋出的功能與還沒有要釋出的功能隔離，只有要是出的功能才會合併到主線，但這樣真的合理嗎？事實上這類功能應該是透過 Feature Toggle 去解決，而不是依靠 Git，應該讓 Git 做好程式碼版本控制就好。

所以往後當我們遇到在 Git 分支策略或是使用上的問題，不妨省思這是不是應該在軟體架構、或是程式碼內就應該解決的問題呢？

三、只存在一個主線就好

從 Git Flow 開始，就常看到雙主線的分支策略，許多 Repository 都同時存在著 master 與 develop 兩個分支。但事實上在 Git Flow 中，master 分支是用來作為一個確定發佈的功用，既然如此，何不開一類分支或是直接在單主線上 Tag 專門做發佈的職責呢？

有嚴格遵從 Git Flow 就算了，但是更多情況是許多 Repository 只有 Follow 到雙主線的概念，卻沒好好遵守其他流程，導致一下在 master 開發、一下在 develop 開發，版本控制變得更加紊亂，很容易在 master 做了點修正，卻忘記也套用回 develop，導致很難有一個統一的測試環境，也讓除錯更加困難。

所以我們可以好好反思真的有需要雙主線嗎？還是就認真讓 master 作為唯一的主線，所有開發、變動都會先合併到 master，再另外有策略去釋出，看是透過 GitLab Flow 去依照佈署環境新增發布用分支、或是像 TBD 在每次新功能釋出時就發出一個新的主線。更重要的是，跟隨前面講「讓 Git 專心做好自己版本控制的角色」，善用 feature toggle，以及善用 Cherry pick 去套用 fix 到發布分支上。

附錄 A、待敘項目

• 各 Workflow 比較表