Git 版控到底有沒有正確的用法?

某天，朋友向我詢問一個問題 ：『Git 版控到底有沒有正確的用法?』

因為團隊成員要求走自己習慣的 Git 協作流程，溝通無效，team member堅持 : 『像是 Git 這樣的工具，使用時沒有絕對的對錯，不是國外的大神說的就是對的，也沒有觀念是否正確的問題…』。

『很有魄力耶』我說。
『但這樣我很困擾啊』朋友無奈地問:『Member這樣講是對的嗎?』

我回答道：
『你可以說對，也可以說不對。
所有東西都是工具，甚至，廣義來說整個軟體開發技術也都是工具，
常常需要因時因地制宜，因此…
對錯是相對的沒錯，但是到底相對於什麼呢? 得看目的。』

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

拿 git working flow來說，如果是早年的 Git 使用者，多半選擇 git flow，那是有當年時空背景因素的。Git 發展初期，需求是開源專案，開發人員可能並不在同一個辦公室協作，常有跨國合作的需求，當時網路狀況也不像現在品質那麼好，那時分支的建立就相當多且頻繁。

再加上 Git 切分分支的成本極低，到後期，甚至有很多團隊用分支來做為暫時性的程式碼存放或測試，這本身不是問題。但這些分支，終有一天需要合併，每次合併，都帶來不少的痛苦。過去沒有頻繁交付的需求，一兩個月合併一次花花時間，日子也就這麼過了，但如今，不同了。

最近幾年，我們是不建議切出具有長生命週期 且 數量多的分支的，因為分支本身就是一種程式碼隱藏，Continuous Delivery 的作者 Dave Farley 就說過， 從頻繁交付的角度來看，具有長生命週期且多分支的 git flow 是個不好的選擇:
https://www.youtube.com/watch?v=_w6TwnLCFwA

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

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

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

這就是技術能力較好的團隊，之所以對於 Git 版控會傾向於選擇不用 git flow 或走 trunk based development 的原因，但這當然必須建立在團隊的技術能力已經足夠成熟的前提上。

資訊業，是一個在持續發展中的行業，改變不僅相當頻繁而且往往昨是今非，因此，不同的團隊、不同的公司、不同的時空背景，同一個議題也可能會有不同的解答。

所以觀念正不正確，或選擇對不對，是依照 “目的” 來決定的，如果團隊的目標一致，選擇就是一種策略，對的選擇，就會讓團隊以更快的腳步接近目標，反之亦然。

所以你覺得，使用 Git 有沒有所謂的對錯呢?

參考文章:
https://www.youtube.com/watch?v=_w6TwnLCFwA
https://www.atlassian.com/continuous-delivery/continuous-integration
https://martinfowler.com/articles/continuousIntegration.html
https://techblog.lycorp.co.jp/zh-hant/Safely-Deliver-Large-Scale-Feature-Migration-With-Feature-Toggle

---

相關課程：

敏捷開發與Azure DevOps實戰
https://www.studyhost.tw/NewCourses/ALM