Patterns for Managing Source Code Branches 系列:
團隊的 GIT 分支管理策略 (1) : 基本概念
團隊的 GIT 分支管理策略 (2) : 主線整合與功能分支 (本篇)
團隊的 GIT 分支管理策略 (3) : 持續整合以及相關比較
團隊的 GIT 分支管理策略 (4) : 發佈的分支模式
團隊的 GIT 分支管理策略 (5) : 其他分支模式
繼第一篇講述基本概念之後,我們來看看整合模式有哪些,以及整合頻率對於團隊效率的影響。
分散式版控讓我們在不互相干擾的情況下進行開發,但最終還是要整合在一起。因此所謂的分支策略其實就是在講『如何整合&何時整合』。
直接在本地端 master 開發,完成後提交到主線 (origin master)。
承前文,主線代表了團隊發佈的基準,這裡是建立變更的起點,也應是變更的終點(開發開始 → 開發完成)。接下來用範例來看整個主線整合的運作:
要注意的是所謂的主線整合必須要完成上述 1–6 步驟,因為 1–5 步驟時,其他團隊成員從主線是完全看不到新的變更的,唯有完成第 6 步驟把變更整合回主線,才是一個完整的主線整合流程。
在這樣的情境下如果有成員們需要一起協作,但又不想直接透過主線溝通整合,那可以採用 協作分支 的方式(其實就是這兩個成員對這次協作的主線)。
每開發一個(或一小群)功能,即建立新的功能分支,開發完成時合併回主線
功能分支目前算是業界產品開發的標準配備,在討論另一種做法 持續整合 之前,先來看看整合頻率的影響。
State of Dev Ops Report 顯示整合頻率與團隊效能為有正面的關係。接下來透過不同頻率的整合來看看為什麼會有如此的影響。
然後 Violet 就會發現主線多了一大包,包含了 S1-S5 的變更,必須要與自己的 V1-V6 整合
『誰叫你不早點 push』Scarlett 說。
假設 Scarlett 跟 Violet 作法與前例相反呢?如果他們每次 commit 都直接整合至主線
前面兩種截然不同範例的整合過程大略如上圖,影響最大的是整合(黃色八角形)的大小,越大的八角形代表越多的整合工作。如果功能切分的乾淨,兩個不相干功能的整合不管再怎麼大可能也會很輕鬆。但如果剛好碰到同樣的區塊,又都在大改架構,那就只能自求多福希望自己是先 push 的那個了,動作慢的倒霉鬼可能需要花上一天甚至數天來處理整合上的問題,這也衍伸出一個名詞 — 『整合恐懼』。
從另一個角度來看,從衝突產生到被對方發現的時間如下圖
可以看到低頻率時整個衝突從產生到被發現會經過一整個功能開發的時間,這中間還會累積更多的不同衝突。高頻率時這樣的衝突累積相較會小很多,搭配健康分支概念,就可以把需要處理的範圍限縮在當下 commit 的變更內。
其實整個產品開發同時也是個溝通的過程,有時候我們需要透過版控工具做溝通。當整合頻率高時,其他人比較容易知道彼此的進度以及掌握整體的變化。當我們需要更高頻率的整合並且同時維護主線健康度時,就很自然的會需要縮減功能大小。這會附帶其他好處:更快的發佈、更快的使用者回饋、更快的學期、決策以及下一次迭代。
講了主線整合以及目前主流的功能分支,並且探討整合頻率對於團隊效率關係,下一章將會討論持續整合以及其與功能分支的比較。
原文出處:團隊的 GIT 分支管理策略 (2) : 主線整合與功能分支
第三篇:團隊的 GIT 分支管理策略 (3) : 持續整合以及相關比較
前後端技術、 UI/UX 、產品開發、資料分析
很雜,真的很雜
網頁開發雜記:https://www.facebook.com/thingsaboutwebdev/
fin的Medium:https://useme.medium.com/