功能分支是邪惡的：從SVN遷移到Git經驗

banq發表於2021-07-16
Git

這是敏捷教練THIERRY DE PAUW分享他建議基於Git主幹分支開發的思路和經驗教訓：
2012 年，我開始了一項技術指導任務，以提升一個新手團隊的軟體工程技能。從工程的角度來看是新手，而不是從工作經驗的角度來看。他們的工作經驗從 5 年到 20 年不等。
一開始，我們遇到了一個我們沒想到在 2012 年仍然會發現的情況。團隊中除了一個人之外，沒有人在使用任何版本控制系統。程式碼在團隊成員之間使用……共享驅動器共享。部署也發生在……共享驅動器上。
 

首先使用SubVersion
顯然，作為第一個動作，我們引入了版本控制。由於團隊是使用版本控制系統的新手，我認為 Git 會成為一座橋樑。需要學習的概念太多。因此我建議使用SubVersion。它很容易使用。你只需要掌握三個概念：

  • 你看看程式碼，
  • 你修改它，
  • 然後您將其重新簽入。
  • 你已經完成了。相當簡單，不是嗎？

因為從各方面來看，SubVersion 分支是相當痛苦的——比 CVS 麻煩，但比 Git 要求更高——我還建議根本不使用分支。團隊中的每個人都將直接投入主幹。坦率地說，當時我對分支策略瞭解不多。這一切對我來說似乎太複雜了。我很難在腦海中適應工作流程。
那效果很好。因為……我們從一開始就引入了第二件事，即持續整合的實踐和 團隊承諾，即任何更改都必須由自動化測試覆蓋，最好是單元測試。
持續整合後來演變為持續交付。
當時，我沒有意識到這是一個有效的分支策略。而且它實際上有一個名字。幾年後我才發現它被命名為 Trunk-Based Development。
 

使用Git
當團隊成熟時，我們認為是時候遷移到 Git 了。做出這一決定的原因有兩個：

  • 有更多工具可用於管理 Git 儲存庫；
  • 我們希望採用 Pull-Request 模型進行程式碼審查，因此分支建立必須毫不費力，沒有摩擦。

但是……對於核心團隊維護系統並接受外部貢獻的開源社群有用的方法，對於企業環境中的同地團隊來說不一定非常有效。
與團隊一起，我們猛烈地解決了功能分支帶來的問題。分散式版本控制系統 (DVCS) 的支持者依靠功能特徵分支來銷售 DVCS 以及圍繞 DVCS 存在的所有工具這一事實使每個人都對使用特徵分支所產生的問題視而不見。
我們試圖透過引入越來越複雜的過程和越來越複雜的技術來尋找解決方案。但它從來沒有真正解決潛在的問題，除了增加了大量的複雜性。最後，我們坐在一起討論這件事，決定放棄使用功能分支。我們回到了對我們有用的東西，即基於主幹的開發。我們從未回頭。
 

八年後
8 年後的 2021 年 1 月，我受團隊組織的邀請， 作為培訓的一部分展示了Feature Branching is Evil。在問答過程中，我發現團隊還在實踐基於主幹的開發。他們仍然無法想象一種不同的工作方式。對他們來說，這是最自然的事情。
 
經過這次經歷，在 2016 年的某個時候，我在一個完全不同的組織中開始了新的使命。非常敏捷，與技術嫻熟的工程師一起工作，大多數時候每個人都是結對工作。但是……他們決定作為一個組織使用GitFlow。到達時，我發現分支機構的壽命從 5 天到 30 天不等。人們不得不頻繁地將主線重新設定到他們的分支中，這導致了大量的返工，並花費了大量無價值的時間來修復損壞的東西。
憑藉我在該新手團隊中獲得的經驗，我建議進行基於主幹開發的實驗。
自 2015 年以來，DevOps 狀態報告已經報告了基於主幹的開發 來預測高軟體交付效能；
Facebook、Microsoft、Netflix 和 Google 等組織大規模實施了基於主幹的開發

相關文章