基於主幹的開發
1. 概述
在本教程中，我們將了解版本控制系統 (VCS) 中基於主幹的開發方法。
首先，我們將探討一般概念，看看它與功能分支開發模型有何不同，涉及的共同特徵以及實現它的工作流程。
然後，我們將討論進行基於主幹的開發時要考慮的不同因素。最後，我們將了解使用基於主幹的開發的優點和缺點。
2.什麼是主幹開發？
基於主幹的開發是一種原始碼控制分支模型，開發人員在稱為「主幹」或「主線」（Git 中的「master」或「main」）的單一分支上工作。
由於此模型中沒有長期存在的開發分支，因此通常可以避免合併衝突，且建置不會經常中斷。
在基於主幹的開發方式中，開發人員主要在「主幹」上進行協作。然而，較大的團隊可能會使用生命週期不超過幾天的分支。
開發人員經常提交程式碼以將最新副本推送到主幹中。隨後，建置會觸發自動化測試，這有助於最大限度地減少後期的整合問題。
正如我們所看到的，這種方法鼓勵持續集成，最適合小型敏捷團隊。
3. 與特徵分支模型的比較
基於功能分支的開發是團隊選擇實踐最常見的方法。在這種分散的版本控制方法中，開發人員從主程式碼庫建立長期專用分支，以隔離特定功能/改進所需的變更。
一旦程式碼準備好並經過測試，就會提交到相應的分支。最後，在解決合併衝突後，這些分支將合併回主程式碼庫。
這裡的想法是讓開發人員能夠獨立工作並提交更改，而不會影響其他開發人員或團隊。具體來說，這對於具有多個貢獻者和/或複雜程式碼庫的相對較大的專案非常有用。
4.主幹開發特點
基於主幹的開發方法有一些共同的特徵。這些因素會影響開發人員之間的工作和協作效率。讓我們簡單地看看它們。
4.1.持續集成
在基於主幹的開發中，所有開發人員都在單一分支（主幹/主幹）上工作。這可以實現更快的程式碼集成，從而減少合併衝突。
開發人員盡可能頻繁地整合程式碼更改，而不是等待大量新程式碼。
4.2.小而頻繁的提交
定期整合小而頻繁的提交可以避免在後期進行大合併的風險。隨後，合併將變得更加容易，衝突也相對較少。
此外，由於提交更加規律，引入錯誤的機會也很小。此外，識別和解決合併衝突要容易得多。
4.3.測試自動化
測試自動化是基於主幹的開發模型的重要特徵。由於有定期提交，我們需要確保建置不會被破壞。此外，新的提交不應引入回歸。
增加測試覆蓋率有助於降低迴歸風險，並有助於快速修復已識別的問題。
此外，這些自動化測試提供即時回饋，以便更快地解決問題，從而提高程式碼品質。
4.4.程式碼審查
對於每個新提交，其他開發人員都會在將程式碼合併到主分支之前進行審查並提供回饋。這有助於提高程式碼品質並提前識別潛在問題。需要定義完成程式碼審查的時間範圍，以便不會延遲提交。
4.5.沒有長壽的分支
任何超過兩天的分支最終都可能成為長壽分支。在基於主幹的開發中，避免長期分支以防止合併衝突並允許更快的整合。
5. 工作流程
讓我們來看看基於主幹的開發模型涉及的主要步驟。
5.1.程式碼變更
第一步，一旦程式碼準備好，開發人員將程式碼直接提交到主幹或從主幹創建的短期分支。在這裡，**經驗法則是每個人每天都致力於主線**。
更準確地說，我們在本地儲存庫中不應該有超過一天的工作未整合。
5.2.請求請求
提交程式碼後，開發人員會建立拉取請求以將新程式碼與主分支合併。
拉取請求將包含更改的基本描述、程式碼變更清單以及任何其他相關資訊。
5.3.程式碼審查
在此步驟中，其他開發人員將審查拉取請求中的程式碼變更。此步驟有助於辨識原作者可能漏掉的缺陷。
此外，對新程式碼進行四眼驗證可以強制新開發人員採用最佳實踐。
5.4.自動化測試
基於主幹的開發很大程度上依賴自動化測試。這些測試包括建立拉取請求時自動觸發的單元測試和整合測試。
自動化測試可防止新程式碼變更破壞現有功能。更重要的是，它讓人確信新程式碼可以正常運作，而不會影響舊程式碼。
5.5.合併
通過同儕審查和自動化測試後，新程式碼就可以與主幹合併了。由於沒有長期存在的分支並且提交間隔很短，因此我們最大限度地減少了合併衝突的風險。
六、主幹化發展的影響因素
在基於主幹的開發和功能分支開發之間進行選擇時，多種因素會產生影響。
具體來說，我們應該照顧專案和所涉及的開發團隊的具體需求。這兩種開發方法都有其優點和缺點。然而，要考慮的主要因素包括程式碼庫的複雜性、實際開發過程以及開發人員的數量。
讓我們看看基於主幹的開發的主要優點和缺點是什麼。
6.1.優點
- 速度和效率：由於團隊在單一分支上工作，基於主幹的開發由於頻繁簽入而可以實現更快的程式碼集成，從而減少合併衝突。因此，團隊可以享受該模型提供的速度和效率。
- 更高的程式碼穩定性：頻繁簽入還有助於檢測和修復任何程式碼問題。由於沒有長期存在的分支機構，我們避免了更大合併的風險。換句話說，當我們更早發現問題並修復它們時，這會帶來更高的程式碼穩定性。
- 增強的團隊協作：與開發人員在各個分支上工作的分支模型相比，基於主幹的開發透過提供對所有當前變更的更多認識來促進相互之間的良好理解和更好的協作。
- 持續整合和交付（CI/CD） ：透過頻繁提交，開發人員確保主幹中的程式碼始終是最新的。在這樣做的同時，他們確保建置始終通過，如果出現任何失敗，都會立即解決。隨後，主幹中的程式碼將始終處於可部署狀態。
- 減少技術債：在與長期分支合作時，開發人員可能會尋求快速修復，這可能會導致新的技術債。在基於主幹的開發中，借助頻繁的合併和較小的提交，我們避免了大型合併以減少技術債務。
6.2.缺點
- 破壞建置的風險：由於開發人員更頻繁地提交，因此總是有可能破壞建置。當建置失敗時，我們可能需要更多時間來修復它並使其再次通過。
- 更改隔離：存在混合兩個或多個更改而不單獨測試這些單獨更改的風險。開發人員需要做好準備，並且始終知道當前的程式碼庫可能隨時更新。
- 發布管理：在主幹中維護不同的程式碼庫很困難。因此，如果我們需要中間發布，那麼發布管理可能會變得令人頭痛。
- 開發人員數量：如果開發人員數量較多，主幹上的工作可能更具挑戰性。如果流程不清晰，團隊協作可能會受到影響。
七、結論
在本文中，我們概述了基於主幹的開發在現代軟體開發中的用法。
同時，我們也簡要討論了基於主幹的開發模型的特點和工作流程。在這個主題上，我們也比較了基於分支和基於主幹的開發之間的差異。
最後，我們看到了使用基於主幹的開發的優點和缺點。總而言之，對於想要簡化開發流程、改善團隊協作並減少技術債的團隊來說，基於主幹的開發值得考慮。