決定因素

發布週期

有許多因素會導致壓力增加，進而使團隊延長發布間隔，以下是其中一些因素：

迭代長度

不同的敏捷團隊專注於不同的迭代長度。有些團隊每三週進行一次迭代，有些是每兩週，還有一些是每週一次。有些團隊甚至根本沒有迭代 —— 特別是實行持續交付的團隊。

如果你的迭代長度是四週或更長，而且每四週的工作內容隨著發布日期的接近而有所變化，且無法改變，你可能會陷入困境。你可能能夠遵循主幹開發的原則，從持續整合的精神中受益（因為所有的分支模型都可以），但你不太可能實現完全的持續交付（或持續部署）。

瀑布式開發模型

這很簡單。如果你正在使用瀑布式開發模型，你距離主幹開發所需的「不要破壞建置」的信條很遠。考慮使用像是極限開發這樣的短週期敏捷方法。

故事大小

主幹開發需要你擁有小型的故事或任務。理想情況下，你開始進行一項更改的工作，應該在幾小時內完成並提交進行程式碼審查。如果時間超過幾天，就會讓一群開發者在非主幹分支上進行合併時產生壓力。或者，讓開發者從你正在進行的分支中建立分支或分叉出分支。或甚至是，盡管你的更改尚未完成，但進行中的分支會接受中間合併。

一般來說，開發團隊應盡其所能將任務分解。敏捷開發裡有一個名為 INVEST 的方法 ，有助於將任務分解成更小的顆粒。

建置時間

保持建置時間短是很重要的，因為它直接影響了開發者一天內能夠提交的次數。如果建置時間只有幾分鐘，開發者能夠保持高效率。但如果建置時間長達 30 分鐘或更長，開發者的節奏會因此減慢，每天可能只能提交幾次，進而影響他們的工作效率。

版本控制系統技術選擇

你的版本控制或原始碼控制技術選擇應該促進團隊每天從主幹更新、拉取或同步多次。在你已經擁有最新版本的情況下，更新、拉取或同步的過程應該少於 3 秒。如果共享的主幹版本比你的還新，則更新、拉取及同步的時間不應超過 15 秒。

舊版本的 ClearCase 和 PVCS Dimensions 執行更新、拉取或同步等操作可能分別需要 30 分鐘和 45 分鐘。如果兩位團隊成員同時嘗試進行更新、拉取或同步操作，則可能需要將這個時間加倍。在這種配置下，團隊完全無法實踐主幹開發。

版本庫中的二進制文件？

取決於二進制文件的數量和更新頻率，一些程式碼管理（SCM）、版本控制系統（VCS）或原始碼控制技術比其他技術更適合。 Perforce 能夠處理 TB 級別的二進制文件和文字資源。Subversion 致力於實現這一目標。Git 只有在配置了 Git-LFS 模式 時才能處理大型二進制文件。

版本庫大小？

建議 Git 和 Mercurial 的版本庫歷史（忽略 Git-LFS）不應超過 1 GB 。有一些實際案例報告 clone 版本庫的大小遠遠超過這個限制，但開發團隊建議將 1 GB 作為上限。為了使用 Git 並突破這個限制，你可能會遇到必須不斷對版本庫進行歸檔，並開始一個新的不帶歷史記錄的版本庫以獲得更多空間的情況。歸檔可能看起來像是在 GitHub 中重新命名版本庫，並將其設置為唯讀，以便所有的歷史、問題和程式碼審查評論都保持完整。更簡單的 clone 優化策略可能包括在 clone 時建議使用 --shallow-since 日期，或利用更近期的部分 clone 功能來 clone 完整的版本庫提交歷史，直到需要歷史數據才會去獲取歷史二進制大型物件 (blob)。

提交的最高頻率

在「純粹」的 Git 中，如果一位同事在你準備推送時已經提交或推送了一個分支（他們的程式碼審查和自動化持續整合已通過），Git 會通知你必須先進行拉取。你執行拉取操作，解決合併衝突（希望沒有），然後再次推送。在活動頻繁的版本庫中，你可能會很難找到一個足夠長時間的窗口來推送，而不會遇到相同的問題。這被稱為「推送競賽」。

在托管的 Git 服務中，基於分支的「拉取請求」和類似前者的「合併請求」一定程度上解決了這個問題，只要不出現衝突，機器人就會自動保持拉取請求分支與 origin:main 同步。

如果你使用 GitHub 當作程式碼版本庫主機，有一個工具可以幫助解決「推送競賽」的問題。這個工具叫作 Bors-NG ，是 Github 上一個拉取請求的合併提交機器人服務。這個機器人服務將負責將最新的主幹版本合併到你的分支中，運行所有需要的測試，然後將結果合併回主幹中，以佇列方式管理這個過程，消除這些推送競賽。

然而，即使使用了拉取請求，對共享版本庫進行非常高的提交頻率也意味著競爭和人工序列化。微軟承認這是他們 Git 虛擬文件系統（Git Virtual File System） 的動機之一（現在僅適用於 Windows ）。

我們可以肯定，在未來幾年內，Git 也將能夠處理大規模專案。無論是使用微軟的技術還是其他技術。

康威定律

組織建立的應用程式和服務反映了組織自身的結構 。如果你的組織是這樣的話，而單一版本庫（Monorepo）感覺不適合，那麼微服務（Microservices）可能是你的方向。

資料庫遷移

為了以主幹開發的方式管理資料庫架構，你需要找到一種方式來處理資料表結構的變更，甚至是在發生新增或修改欄位的資料表中，管理其中已有的資料。 Pramod Sadlage 和 Scott Amber 的書《Refactoring Databases: Evolutionary Database Design》 以及 《Continuous Delivery》 書籍更深入地探討了這一點。

共享程式碼

主幹開發團隊通常對於原始程式碼樹不同部分的貢獻有共同的程式碼所有權規則。如果沒有完全平等的系統，他們會為原始程式碼樹的貢獻制定客觀的規則。這些規則專注於標準並承諾進行優先和公平的程式碼審查。主幹開發團隊可能會對主幹內的目錄設置細粒度的寫入權限，但對於讀取主幹中的文件絕對不會有任何障礙 —— 每個人都可以看到所有內容。