---
title: Trunk-based Development - 簡介
tags: Books,TBD
---

## 一言以蔽之

這是一種原始碼控制的分支模型，開發人員在稱為「主幹」的單一分支中進行協作，通過此份文件所說明的技術，來抵抗建立長期開發分支的壓力。因此，他們避免了合併地獄，且不會破壞建置，從此過上幸福的生活。

## 主線之外的共享分支在發布節奏是不好的


## Trunk-Based Development 用在小規模團隊


> 小規模團隊（1-2 人）基於 TBD 開發的情境

## 大規模的 Trunk-Based Development:


> 大規模團隊（>2 人）基於 TBD 開發的情境

## 闡述，聲明，注意事項


TBD 的開發方式是 CI 與 CD 的關鍵要素，當團隊內的每個人每天能對主幹持續提交變更, 能變得很容易去滿足 CI 的核心需求。這樣子做的好處確保了 codebase 總是能按需求發布。並且有助於實現持續交付。

> [Continuous Integration](https://trunkbaseddevelopment.com/continuous-integration/) 與 [Continuous Delivery](https://trunkbaseddevelopment.com/continuous-delivery/)

小團隊 TBD 與大規模的 TBD 的分界線的維度是團隊人數與提交頻率來做考量。具體來說。何時該從小規模變成大規模是值得爭論的。無論如何。團隊成員要提交或推送到版本庫給別人或機器人看到之前，要先執行完整的「預先整合」（pre integrate）建置（編譯、單元測試、整合測試)

> 可參考 CI 的開發人員的七項實踐

### 聲明

- 應該進行 TBD 的開發流程來取代 GitFlow 或其它的有多個長生命分支的策略模型
- 可以直接對 Trunk 做提交/推送(小規模團隊) 或者用 PR 工作流程, 只要這些功能分支是短生命的且你屬於一人產品團隊.

> 譯者註：TBD 與 GitHub Flow 比較接近，GitLab Flow 比較像變形

### 注意事項

- 根據團隊人數規模與提交頻率, 短生命週期的功能分支被用來code-review和編譯檢查(CI), 而不是用來做artifact的生成與發布, 在提交陷於主幹被其他開發人員拿來用甚至看到之前. 這些分支讓開發者們熱衷於review. 非常小的團隊可能直接提到到trunk.
- 根據想要的發布節奏, 有些發布分支可能會從trunk被切出去, 且不會在被合併回來了, 且這些被切出去的分支通常不久後就會在發布後被刪除. 或者, 團隊也可能從trunk直接發布, 並且選擇"fix forward"的策略來修復bug. 從主幹直接發布適合用於高產能團隊.
- 團隊們應該花點時間來適應抽象分支（[branch by abstraction](https://trunkbaseddevelopment.com/branch-by-abstraction/)）也能使用 feature flags 讓每天持續的開發人員的產出也能對做發布，又能避險，讓還沒要公開或有風險的功能做公開。