前情提要

昨天我們介紹了gitlab Flow，今天雖然要介紹branch strategy，但他其實不一定需要分支。

Trunk-Based Development

看到它的名字就很特別，人家都是git flow, github flow, gitlab flow，xxx flow，就他是development。

它的精神是開發人員每天要至少一次將他們的改變push到主幹中。這個主幹要可以隨時發布。
這代表什麼事情呢，它希望開發人員更頻繁地進行小的修改，目標是限制分支的生命週期，並且避免衝突。因為大家都在同一條船上，有衝突時也因為是較小的修改，我們可以快速的修復問題，才不會發生git flow，github flow那樣一堆分支在外面的狀況，最後合併困難。

pros

• 簡單
• 快速release
• 互相合作機會增加

我們的主幹上是隨時可以部屬的code，能夠快速的作CICD，也因為大家都在同一條分支上工作，互相合作的機會會更多。

cons

缺點就是大家如果都推到主幹上，就可以跳過code review的環節。如果有人將沒測試的code推上去，wow，會發生什麼事情呢XD

另外因為在同一分支開發，會很頻繁的解衝突，這對開發人員也是一個負擔。且需要跟人頻繁的溝通，也會消耗大量的時間和精力。

還有其他招嗎?

聽起來這個缺點也是很多，難道沒有更好的方法嗎? 有，TBD還有另一個方法Scaled Trunk-Based Development

Scaled Trunk-Based Development

此分支策略使用生命週期最長只能幾天的短期分支feature，並合併到隨時可部屬的trunk分支。這樣就可以再合併時進行code review，而且也避免長期存在的feature分支合併上的問題。

看這圖是不是越看越熟悉呢?

• 上圖為github flow

沒錯他跟github flow是長得很像的，他們都是有feature分支，以及main分支，但Scaled Trunk-Based Development強調feature branch的生命週期是要很短的，最長可能只有幾天就要被合回去trunk分支。這樣就可以有pr的環節啦!

那使用TBD可能會碰上一個問題，如果要上線時，我們的trunk分支上的code有未完成的功能怎麼辦!因此有些團隊就捨棄TBD去用具有長期生命週期的feature分支。

總結

有一好沒兩好，總是會有不如意的地方，那麼怎麼選擇呢?

如果小團隊，推薦使用github flow以及TBD
如果需要持續的部屬以及release，最推薦使用github flow以及TBD
如果對產品品質有要求，還要能持續部屬的話，推薦gitlab flow，
它具有code review，加上可以切分環境、版本的特性，比較適合這狀況。

reference

https://www.stevesmith.tech/blog/organisation-pattern-trunk-based-development/

https://dev.to/reviewpad/git-hub-flow-trunk-based-development-and-code-reviews-58ng