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