譯者 | 劉汪洋
審校 | 重樓
如今，分布式版本控制系統(tǒng)，例如 Git，在版本控制領(lǐng)域已然成為主流。有人認為，使用像 Git 這樣的版本控制系統(tǒng)（VCS）進行分支和合并非常便捷。但我更推崇基于主干的開發(fā)（TBD），現(xiàn)在我將解釋其中的原因。
在基于主干的開發(fā)模式中，所有開發(fā)人員都在同一個分支（例如 'main'）上工作。你可能已經(jīng)從 Martin Fowler 或 Dave Farley 那里了解過相關(guān)討論。當 Git 迅速成為首選版本控制系統(tǒng)時，通過與 Dave 的合作經(jīng)歷，我親身體驗到了團隊在持續(xù)交付環(huán)境中基于主干開發(fā)所帶來的優(yōu)勢。
與此不同，分支模型則鼓勵開發(fā)人員為每個特性、錯誤修復(fù)或增強功能創(chuàng)建獨立的分支。雖然分支在隔離變動和降低風(fēng)險方面看似合理，但許多因素讓我更傾向于基于主干的開發(fā)方式。
1. 速度與效率
主干開發(fā)模式下，整個團隊在同一分支上協(xié)作，從而實現(xiàn)更迅速的集成，并減少合并沖突。這正是持續(xù)集成（CI）的核心理念。雖然現(xiàn)在提到 CI 時通常是指“每次提交時在團隊服務(wù)器上運行構(gòu)建和測試”，但CI的本質(zhì)是確保代碼能夠定期并順利地集成。獨立分支的代碼未集成，且存在時間越長，合并回主代碼庫的難度越大。獨立分支上快速開發(fā)的修復(fù)和改進似乎很迅速，但最終還是有代價的。定期集成小的更改通常比長時間后進行大型合并更為輕松。
2. 代碼穩(wěn)定性增強
主干開發(fā)鼓勵頻繁提交，從而產(chǎn)生小型、易于管理的更改。頻繁拉取其他開發(fā)人員的更改，并推送小型、有效的代碼更改，有助于確保代碼庫的穩(wěn)定性和可用性。如果有 CI 服務(wù)器為每次提交運行構(gòu)建和測試，驗證這種“穩(wěn)定和可工作”的假設(shè)就更方便了。任何時候構(gòu)建中斷，我們必須暫停提交，專注于修復(fù)。在構(gòu)建中斷時持續(xù)推送更改將無益于任何人。
在分支模型下，龐大、不頻繁的合并可能會因更改的規(guī)模而難以定位和修復(fù)錯誤。當他人合并了大型工作后，你是否曾發(fā)現(xiàn)自己的代碼不再工作？如果你和他人做了許多不同或重疊的更改，找出導(dǎo)致測試失敗或應(yīng)用程序工作不正常的原因可能會耗費很長時間，而這還需要你有可靠的測試覆蓋率。
3. 加強團隊協(xié)作
結(jié)對編程是我最喜歡的團隊成員之間的知識共享方式，雖然我知道并不是每個人都能這樣做（有關(guān)此方面的更多信息，可以查看 JetBrains 的 Code With Me）。如果沒有配對，至少團隊應(yīng)該在同一代碼上工作。如果每個人都在自己的分支上工作，那么他們其實是在相互競爭而非協(xié)作，還可能會因為擔(dān)心被他人的更改壓倒而過于小心翼翼。
若團隊都在同一分支上工作，通常會增進對正在進行更改的理解，促進團隊協(xié)作和知識共享。相反，分支可能造成孤立的工作環(huán)境，導(dǎo)致團隊內(nèi)部的知識空白。
4. 持續(xù)集成與交付（CI/CD）實踐的優(yōu)化
Dave Farley 的書籍 “持續(xù)交付”，以及相關(guān)博客文章和視頻，都深入強調(diào)了“主干開發(fā)模式與持續(xù)集成和持續(xù)交付（CI/CD）實踐的天然相容性”。
在主干開發(fā)模式下，持續(xù)集成的實施更加直接，因為代碼會頻繁提交到主干分支，而這也正是 CI 環(huán)境所構(gòu)建和測試的分支。任何的失敗都能及時發(fā)現(xiàn)并解決，從而降低了重大故障的風(fēng)險。通常，追蹤引起問題的具體更改相對容易。如果某個問題無法立即解決，可以回退導(dǎo)致該問題的具體修改。
現(xiàn)在我們應(yīng)該明白快速反饋循環(huán)的價值，因為它能讓我們更快地發(fā)現(xiàn)問題、找到原因，并迅速修復(fù)，從而提升軟件的質(zhì)量。
在主干開發(fā)環(huán)境中，持續(xù)交付也得以蓬勃發(fā)展。成功的持續(xù)交付要求始終保持代碼庫可部署的狀態(tài)。主干開發(fā)方法通過促進頻繁的提交、集成，以及對所有集成的全面測試，確保了這一目標的實現(xiàn)。任何時候引入的細微修改都使得軟件部署和測試更為順暢。
相較之下，使用分支模型來實現(xiàn)有效的 CI/CD 往往更復(fù)雜、更耗時。雖然有人可能會認為：“我可以在我的分支上運行構(gòu)建和所有測試”，但實際情況是，并非每次提交都進行了真正的集成。直到合并（或變基）的過程中，你才會開始面對任何集成問題。在分支上運行的所有測試，并沒有對任何類型的集成進行實際檢驗。
合并和測試不同分支的代碼可能會引入延遲和潛在錯誤，進而削弱構(gòu)建流水線的某些優(yōu)勢。
5. 減輕技術(shù)債務(wù)
長期維護的分支常造成“合并地獄”現(xiàn)象，這是由于主分支（例如 'main'）與特性分支之間的差異過大，導(dǎo)致合并過程變得異常困難。這種情況可能引發(fā)技術(shù)債務(wù)的累積，因為解決合并沖突時可能會采用快速但非理想的修復(fù)方案，或者接受集成開發(fā)環(huán)境（IDE）的自動建議而可能對其并未完全理解。相較之下，主干開發(fā)、頻繁的合并操作和較小的代碼更改則使技術(shù)債務(wù)的管理和減少變得更為便捷。
總結(jié)
我個人確信主干開發(fā)具備顯著優(yōu)勢，并在實際項目中親自體驗了采用此種方法的團隊效益。然而，這需要團隊共同建立一種思維方式和文化氛圍。這其中涉及頻繁合并他人的代碼更改，經(jīng)常進行小規(guī)模的代碼修改，按部就班地進行增量改動。這可能是一種需要適應(yīng)的開發(fā)習(xí)慣。整個團隊采用一致的方法和文化，關(guān)鍵在于實踐配對編程、全面自動化測試和進行適當?shù)拇a審查。
有序、紀律的主干開發(fā)能簡化流程，增強協(xié)作，提升代碼穩(wěn)定性，支持CI/CD實踐，并減輕技術(shù)債務(wù)。如果你一直采用基于分支的模型，轉(zhuǎn)變可能會面臨挑戰(zhàn)，但從長期來看，優(yōu)勢是明顯的。若你對此感興趣，還可以參閱Dave的文章，他在其中解釋了主干開發(fā)的障礙。
版本控制分支、提交、主干開發(fā)、持續(xù)集成/部署等是軟件開發(fā)過程中的關(guān)鍵概念。
譯者介紹
劉汪洋，51CTO社區(qū)編輯，昵稱：明明如月，一個擁有 5 年開發(fā)經(jīng)驗的某大廠高級 Java 工程師，擁有多個主流技術(shù)博客平臺博客專家稱號。
原文標題：Why I Prefer Trunk-Based Development，作者：Trisha Gee
