Image

今天持續消化訂閱箱的文章，看到一則標題蠻有興趣的，也轉貼上來給大家：
Git 版控到底有沒有正確的用法? - .Net Walker

這篇文章中，作者大大先從 Git Flow 大爆發(?) 的歷史背景提起：

Git 的使用，一般來說，有爭議或選擇的是兩個部分：Repo 大小的分割 (專案顆粒度)，以及 git working flow…

拿 git working flow來說，如果是早年的 Git 使用者，多半選擇 git flow，那是有當年時空背景因素的。

Git 發展初期，需求是開源專案，開發人員可能並不在同一個辦公室協作，常有跨國合作的需求，當時網路狀況也不像現在品質那麼好，那時分支的建立就相當多且頻繁。

但馬上就帶到現在常用的開發狀況，以及持續整合的部份：

最近幾年，我們是不建議切出具有 長生命週期 且 數量多的分支的，因為分支本身就是一種程式碼隱藏。

Continuous Delivery 的作者 Dave Farley 就說過， 從頻繁交付的角度來看，具有長生命週期且多分支的 git flow 是個不好的選擇: https://www.youtube.com/watch?v=_w6TwnLCFwA

所以，如果要實踐敏捷的頻繁交付 (一周數次，一天數次) 那我會建議 git 分支數量愈少愈好，分支生命周期愈短愈好，以便能有利於持續整合，實現頻繁交付

如果你想實踐真正的持續整合(CI)，就要盡可能地減少不力於頻繁整合的程式碼隱藏，而分支，毫無疑問是一種程式碼隱藏

這邊讓我學習到一件事：分支也是一種程式碼隱藏

畢竟某個分支被放在倉庫裡長灰塵後，被藏起來的那些程式碼也沒人知道了

那麼我們是不是讓分支生命週期越短越好就「正確」了呢？當然不是：

但這是有前提的。前提是 : 『團隊有良好的自動化CI流程，包含程式碼的靜態掃描、套件安全性掃描、自動化測試…都必須在Pipeline中出現。』

因此採用 Git flow 或是 Trunk based development 或其他作法，都還是要回到團隊目前的狀況。有沒有達到上面列的前提、有沒有需要持續整合，然後才能去決定。而不是哪個做法一定比另一個做法香。

那麼，今天的轉貼就先到這邊。明天見 ><"

補充：如果有對 Git 分支策略不太熟的朋友，這邊也整理了一些延伸閱讀。有興趣的話也可以看看～

或是可以閱讀本 Blog 的 Git 介紹文章：