鐵人進度來到第 14 天了，我發現我想題目的時間越來越長了 XDrz，若是有鐵友在軟體開發上有什麼想聊的議題，歡迎在下面留言給我。雖然我的見解不一定是最正確，但開啟一個對話的空間也是不錯。

好，那今天要聊的是指版本控制的分支不宜長命，這裡的版本控制特別指 Git，裡面概念不一定完全適用在其他版控中。

通常我們在要專案變動程式碼時，通常會開一個新分支去進行，等到完成的差不多時，再提 Pull Request，請同事幫忙 Code Review，最後併入主線中。在這個過程中，偶爾會遇到有同事在進行的變動可能特別大、或是他因為一直被打斷，所以叉出去的分支遲遲未完成，導致這個分支活了很久都沒併入主線。

這種情況會有什麼問題呢？最容易遇到的問題就是在合併時，因為和主線脫離太久，主線在這之中已經併入了許多變動，導致兩者產生變動衝突，更可能形成要解很久的衝突地獄（conflict hell），雖然這部份可以透過定期 pull rebase 去改善，但也只能算是治標。

再來，這種情況可能會導致成員之間的重工。舉個簡單的例子，可能 A 在某分支進行了重構，但因為一直沒併回主線，B 也在另一個分支的同段程式碼進行重構了。

以及一個很重要的困擾，就是假設 C 的分支做了一個很重要的變動，D 在另一個分支也想基於這個變動去進行開發，但是 C 原本想做的功能還沒做完，所以就遲遲沒有把那份變動併入主線，導致 D 很有可能就被卡住了。

最後，是攸關心理層面的，但一個分支越來越長壽、變動越來越多，卻遲遲沒有併入主線，就會漸漸產生一個恐懼心理，開始不敢併入主線，因為怕變動太多，一併入主線就會爆炸。若真的要併入主線，就得透過各種測試去增加自信，但針對大量變動的測試又得要不少時間與成本。於是，各種開始不自覺因為不敢面對產生各種拖延，導致惡性循環。我認為這是最可怕的部分。

我認為比較好的處理方式，是當你的變動進行到一個小段落，且確定併入主線不會破壞現有穩定度，專案依舊能正常運行，就可以先併入主線了。可以把一個長期目標，拆成好幾個元件似的變動一一合併。比如說，重構程式碼單獨開一個分支進行合併、一個針對原有功能的改進也先開一個分支進行合併、或是建立一個不大的新功能，也可以先合併，但是透過某種方式不立即顯示在產品上等等。透過這種方式就能從根本上避免上述提到的問題了。

至於，若有分支是以大版本為目的去存在的，比如說 1.x.x 和 2.x.x 的這種分支，則不在本討論範圍，對於這樣的的分支有何利弊，可以之後再探討囉。