筆記：TBD是三小?---What is Trunk Based Development?
原文： http://paulhammant.com/2013/04/05/what-is-trunk-based-development/ 讀過了Perforce官方的mainline model的文件，又看到Google與Facebook都使用TBD，以及我自己在開發上遇到的問題，讓我想看看TBD到底如何可以幫助我們解決這些工程上的問題，看起來作者非常反對feature branch，而我自己親身經歷的感受也的確，要開feature branch，除非能做到Perforce官方推薦的經營方式，不然不只Merge會有災難，開發時也是災難連連。以人性角度來說，假設我做componentA，如果有10個feature branch都有componentA，那每個branch有問題我都要去看，我修了一個componentA的問題，由於每個branch分支出去的時間點不同，其它branch有的可能有，有的可能沒有這個問題，那我怎辦，只能等著人家來報問題，那我的時間很多都花在解這些Branch的問題上。如果採用的是TBD的概念，我只要保證trunk沒問題就可以了。或許在code撰寫方式上需要花很多工，但是我只需一次工，也可以將焦點集中在一個地方。對於我這種普通人，這是比較人性化的工作方式。 甚麼是TBD 一個軟體開發的分支模型，也被稱作mainline 同一個產品開發的所有人員共享一個Repository，有一個trunk，單一Developer或是Developer團隊可以有自己的private branch，所有修改最後都會回到主幹 只有在Release時才會有官方的分支，一般Developer不能對Release Branch作動作，只有Release Engineer可以更動Release Branch，當Release Branch完成它的任務，就會被砍掉。 Google與Facebook都採用這種分支模型 有需要Release才Branch Release之後的branch，就不會有大的更動，只有Release Engineer會進行將挑選Commit合併到Release Branch的動作 多一個Release Engineer的帽子 Bug先在trunk修好，之後把Commit合...