Version Branching Strategy
Git Flow
GitHub Flow
GitLab Flow
Mercurial-based
Subversion-based
CVS/PVCS-based
ClearCase-based
Trunk-based
- 開發人員專門致力於單一主幹
- 發布工程師創建發布分支，並專門挑選分支
- 只有當缺陷不能在主幹上重現時，才允許在發布分支上修復它，並合併回主幹。
Feature Toggle
Martin Flower 歸納出來的名詞，這個技巧是用在一些已經實作或是實作中，但還不想開放的功能，有些人以為這是與 TBD 一起用的，其實不然，這招早就存在，分為以下兩種：
- Toggles at runtime，執行時期判斷旗標，看要不要開放此功能。
- Toggles at build time，建置時間判斷建置參數，看要不要把功能相關程式碼 build 進去。
Branch By Abstraction
BBA 的核心概念就在於，用程式架構面的抽象來取代原本習慣在版本控制系統進行的事情，不再透過分支去管理那個 feature 何時要併回主線去發佈，去減少整合上的成本。
比如說今天有一個元件 A 想要更改實作，會先在 A 與依賴 A 的元件中間建立一個抽象層，然後依賴該抽象層去編寫新的實作 B，再把原本參考 A 的元件改成 B，最後就可以把 A 給廢棄了。
這樣的好處在於，透過抽象層的建立，我們得知新的元件應該要實作哪些介面，才可以在取代原先元件時無縫接軌，我們可以編寫新的元件，且不怕影響到現有程式的穩定，並透過單元測試確保新元件的品質。
我們不再需要分支去隔離新元件和舊元件同時存在的版本，也不怕在為了隔離新元件剛開始開發而無法發佈的期間，產生多餘的整合成本。