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)，就要盡可能地減少不力於頻繁整合的程式碼隱藏，...
