iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 14
0
Software Development

軟體開發隨筆談系列 第 14

版控的分支不宜長命

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

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

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

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

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

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

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

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

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


上一篇
釐清 Bug 與預期落差
下一篇
追求自動化
系列文
軟體開發隨筆談31

尚未有邦友留言

立即登入留言