簡介

一行總結

主幹開發是一種程式碼版本控制的分支模型，開發者在一個稱為「主幹」的分支上共同工作，透過採用規範好的技術手段，來抵抗因為長期存在的開發分支所導致的壓力。這可以避免分支合併的痛苦，確保不會破壞版本建置，並持續保持一個隨時可部署的穩定版本。

* 自 2020 年起，Git 社群改用 main 作為主要分支（在此之前使用 master，但帶有不良含義）

在任何發布節奏下，從主幹上建立出共享分支都是不好的：

小型團隊的主幹開發：

大規模團隊的主幹開發：

闡述、主張與注意事項

主幹開發是實現持續整合以及進一步實現持續交付的關鍵推動者。當團隊中的成員每天多次將他們的變更提交到主幹時，就能輕易滿足持續整合的核心要求，即所有團隊成員每 24 小時至少向主幹提交一次。這確保了基準程式碼隨時可以按需求發布，並有助於實現持續交付。

小型團隊的主幹開發與大規模團隊的主幹開發之間的劃分，取決於團隊大小和提交頻率的考量。一個開發團隊何時不再被視為「小型」並已轉變為「大規模」，這是實踐者們的討論主題。無論如何，團隊在提交或推送給其他人（或機器人）查看之前，會在他們的開發個人電腦上進行完整的「預整合」建置（編譯、單元測試、整合測試）。

主張

你應該進行主幹開發，而不是 GitFlow 和其他具有多個長期運行分支的分支模型
你可以直接進行主幹的提交或推送（適用於非常小的團隊），或者進行拉取請求的工作流程，只要那些功能分支的生命週期短暫，並且是單一人員的產出。

注意事項

根據團隊大小和提交速率的不同，短期功能分支用於程式碼審查和建置檢查（持續整合），但不用於產生或發布產品，這些操作在提交到主幹之前進行，以供其他開發者依賴。這樣的分支允許開發者在將其程式碼整合到主幹之前進行積極且持續的程式碼審查。非常小的團隊可能會直接提交到主幹。
根據預定的發布節奏，團隊或許需要即時的從主幹中切分出發布分支，在發布之前將版本「固化（hardened）」，避免團隊有新的活動讓發布版本異動，並在發布後的某個時間點刪除這些分支。或者，如果團隊從主幹進行發布並選擇「立即修正（fix forward）」策略來進行錯誤修復，則可能不會有發布分支。從主幹進行發布也適用於高產能團隊。
團隊應該熟練掌握相關的抽象分支技術，以實現更長期的變更，並在日常開發中使用功能標誌來允許針對發布順序進行避險（以及其他好處——請參閱連續發布的並行開發）。
如果你的專案有多位開發者，你需要連接一個建置伺服器來驗證他們的提交在進入主幹後是否沒有破壞建置，同時也要在他們從短期功能分支合併回主幹時進行驗證。
開發團隊可以隨意調整大小（在主幹中），而不會影響生產力或品質。如果想了解證據，可以參考 Google 實行主幹開發，他們的單一版本庫的主幹中擁有 35000 名開發者和 QA 自動化測試人員，該主幹可以根據開發者的需求擴大或縮小。
實踐 GitHub Flow 分支模型的人會覺得這很相似，但在發布的位置上有一個小差異。
使用 Gitflow 分支模型的人會發現這非常不同，同樣的情況也適用於許多習慣於流行的 ClearCase、Subversion、Perforce、StarTeam、VCS 過去的分支模型的開發者。
許多出版物推廣我們在這裡描述的主幹開發。其中包括暢銷書《Continuous Delivery》和《DevOps Handbook》。這個觀點現在甚至不應該再有爭議！

歷史

自從九十年代中期以來，它一直是一種較少為人知的分支模型選擇，並自八十年代以來被戰略性地考慮。像 Google（如前所述）和 Facebook 這樣的大型開發組織都在大規模地實踐主幹開發。

超過 30 年來，不同的程式碼版本控制技術和相關工具與技術的進步使得主幹開發變得更為（偶爾也會少些）普遍，但這麼多年來，還是有很多人堅持使用主幹開發分支模型。

關於本站

本站試圖將所有主幹開發相關的事實、原因及技巧彙整在同一處，並提供二十五張圖表輔助說明各項內容。全站一次也沒有使用過 TBD 這一縮寫——不，連兩次都沒有。