選取有效的分支策略

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

建立 Team Foundation 版本控制 （TFVC） 存放庫的分支有助於隔離風險。 請考慮小組成員在處理由五或十多人組成之軟體專案時，通常會面臨一些挑戰：

• 該群組有一些（或可能是數個）不同的功能小組，每個小組都處理一組相當不同的功能。 但每個小組也相依於其他小組所建置的功能。 您必須隔離各小組完成的工作所帶來的變更風險，但最終，您必須將他們的所有努力合併成一個產品。

• 測試小組需要穩定的程式代碼版本來測試，但同時，開發人員需要繼續使用偶爾會破壞產品的新功能。

• 軟體有兩個舊版和一個目前版本正在進行中。 儘管大部分的開發工作都投入在目前的版本中，但舊版仍必須支持偶爾的 Service Pack 版本、重大修正和安全性修補程式，以及其他變更。

本文會探索一些常見的分支策略，以協助您做出正確的決策。

與存放庫範圍的 Git 分支不同，TFVC 分支是由路徑範圍定義，且不如 Git 分支輕量。 設定高標準，僅在需要程式代碼或版本隔離時建立分支。

僅限主要

主策略 可以是以資料夾為基礎，或是將 主資料夾 轉換成 分支，以啟用額外的可見度功能。 您將變更提交至 main 分支，並可選擇使用標籤來標示開發和發行的里程碑。

風險：TFVC 標籤的變動性和缺乏歷史記錄可能會增加變更控制的風險。

從唯一的主要分支策略開始，戰略性分支，並根據需要採取其他策略以逐步演變成更複雜的策略。

開發隔離

當您需要維持穩定的 主要 分支時，您可以從 主要分支分支出一個或多個 開發 分支。 它可以實現獨立性和同時開發。 工作可以依功能、組織或臨時合作，在開發分支中進行隔離。

main 分支中可能會有變更。 一律將 （FI） 主要 轉送至 開發 分支，並解決合併衝突。 然後反向整合 （RI） 變更回到主要 。 維持各分支的相同品質標準。 在 主要上以相同方式，建置和執行開發 的建置驗證測試（BVT） 。

注意：採用此策略，小組可能會永遠保留 開發 分支，這可能會累積大量的合併歷史記錄。

功能隔離

功能隔離是開發隔離的特別衍生形式，可讓您將一或多個 功能 分支從 主分支，如圖中所示，或從您的 開發 分支中分支出來。

當您需要處理特定功能時，建立功能分支可能是個好主意。

盡量縮短功能工作及其相關功能分支的壽命。 經常從父分支轉送整合 （FI） 變更。 只有在符合一些已同意的小組準則，例如完成的定義時，才能將反向整合 （RI） 回到父系。 主要 上的功能復原成本可能很高，而且可能會重設測試。

解除隔離

發行隔離會從 主要分支引入一個或多個 發行分支。 此策略允許在發行時間進行並行發行管理、複數和平行版本發布，以及代碼庫快照。

當發行準備好要鎖定時，是時候為發行建立新的分支了。

永遠不要從 的主要開始進行向前整合（FI）。 使用訪問許可權鎖定發行分支，以防止對 版本進行非預期的修改。 對 版本 分支所做的修補程式和緊急修補，可以反向合併（RI）回到 主要 分支。

注意：沒有任何分支情境是不可變的，這就是為什麼您會注意到在發行分支上執行的緊急修補程式。 調整每個策略以符合您的需求，同時考量其複雜性和相關成本。

服務與發行隔離

服務與發行隔離策略引進 維護 分支。 此策略允許在發佈時同時管理服務包和程式代碼基底快照集。

如果您需要一個服務模型，讓客戶可以升級至下一個重大版本以及每個版本的附加更新包，請使用此策略。

如同發行隔離，服務 隔離和 發行 分支會在發行準備好鎖定時建立。 永不從 主要 整合至 服務，或從 服務 整合至 版本。 鎖定 版本 分支以防止修改。 未來的服務變更可以在 維護 分支上完成。

如果您需要該隔離等級，請為後續版本建立新的服務與發行分支。

維護、熱修復、發行隔離

雖然不建議這麼做，但您可以藉由引進其他 Hotfix 分支和相關聯的發行案例，繼續發展策略。

此時，您已成功探索一些常見的 TFVC 分支案例。 您可以進化它們，或調查其他策略，例如 功能切換，以判斷功能在運行期間是否可用。

Q&A

為什麼分支應該短期存留？

藉由讓分支保持短暫，合併衝突可以減少到最少。

為什麼只在必要時才分支？

若要接受 DevOps，您必須依賴建置、測試和部署的自動化。 變更 連續、頻繁和合併作業更具挑戰性，因為合併衝突通常需要手動介入。 因此，建議您避免使用分支策略，並依賴其他策略，例如功能切換技術。

為什麼要移除分支？

您的目標應該是盡快將變更合併回 主分支，以減輕長期合併衝突的後果。 暫時、未使用且豐富的分支對小組造成混亂和額外負荷。

程式代碼基底是否可以在不同的項目之間分支？

是的。 除非小組必須共用來源，且無法共用一般程式，否則不建議這麼做。

代碼促銷策略呢？

程式碼推廣策略感覺就像瀑布式開發時期的舊物。 它通常具有較長的測試週期，以及個別的開發與測試小組。 不再建議該策略。 如需此策略的詳細資訊，請參閱 分支指引。

將 開發 合併至 主要 分支時，為何不會偵測到任何變更？

例如，您可能已忽略先前合併中的變更，例如，使用 keep source 衝突解決選項。 如需詳細資訊，請參閱 將開發分支合併至main：合併 沒有任何變更。

TFVC 與 Git 分支策略之間是否有相似之處？

TFVC 功能隔離分支策略類似於 Git 主題分支。

作者：傑西·胡文、馬庫斯·費爾南德斯、邁克·福利和威利·肖布，屬於ALM | DevOps Rangers團隊。 您可以在這裏 連絡他們。

（c） 2015年Microsoft公司。 保留所有權利。 本文件是以「as-is」提供的。文件中所表達的資訊和觀點，包括 URL 和其他網頁參考，可能會在沒有通知的情況下變更。 您必須承擔使用本文件的風險。

本文件不會提供您任何 Microsoft 產品中的智慧財產權的法律權利。 您可以複製和使用本文件，以參考為目的供內部使用。