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

# TL;DR
...

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

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

一、論述

Chunk Base Development (TBD) 是由 Paul Hammant 於 2013-04-05 在 What is Trunk-Based Development? 提出。

與 GitLab Flow 類似，所有的程式碼都都應該先回到主線 (Mainline)，也就是所謂的 Trunk。但與 GitLab Flow 不同的是，它沒有下游的概念，在程式碼要釋出時，都會另外拉出一條分支，做為當次的 release branch。儘管沒有上下游的概念，但是 TBD 最核心的觀念就是任何變動都應該先並回主線，所以即便是有任何需要 hotfix 的變動，也都要先併回 Trunk，而不是在 release 分支上進行變動。那要怎麼將 hotfix 套用在 release 分支呢？就是使用 git cherry-pick 指令，將那些 hotfix 從 trunk 揀到 release 分支上。

另外有一個很重要的原則必須把握，就是 pick 的變動，只能是 fix，不能是 feature，如果有什麼 feature 要釋出，就要再另外拉一條 release 分支。那這樣有些功能雖然已經併回主線了，但是還不想讓使用者看到怎麼辦？這時候就要搭配 featuer toggle，在新增任何功能時，都應該要先加上 feature toggle，讓我們可以更彈性的釋出功能，而不會被部署給侷限住了。而且使用 feature toggle 的好處，就是讓該功能開關的速度不過是重新設定 toggle 的速度，而不用重新建置、部署，時間上就會跨很多。另外也可以搭配不同的部署方式，加上分流機制，進行 A/B Testing 或是金絲雀測試。

附錄 A、待敘項目

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