選取有效的分支策略

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

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

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

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

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

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

不同於存放庫範圍的 Git 分支，TFVC 分支的範圍是路徑範圍，而不是輕量型。 設定您的列，以在需要程式代碼或釋放隔離時建立分支高，且只有分支。

僅限主要

「僅限主要」策略可以是資料夾型或主資料夾轉換成分支，以啟用其他可見度功能。 您會將變更認可至main分支，並選擇性地指出具有標籤的開發與發行里程碑。

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

從主要的分支策略開始， 以策略方式 分支，並採用其他策略，視需要演變成更複雜的策略。

開發隔離

當您需要維護和保護穩定的主要分支時，您可以從main分支一或多個開發分支。 它可啟用隔離和並行開發。 工作可以依功能、組織或暫時共同作業，在開發分支中隔離。

主要分支中可能會有變更。 一律將 （FI） main 轉送至 開發 分支，並解決合併衝突。 然後反向整合 （RI） 變更回 main。 跨分支維持相同的品質橫條。 在開發上建置並執行組建驗證測試（BVT），就像您在主要上所做的一樣。

注意：使用此策略，小組可能會永遠保留 開發 分支，而可能會建立大型合併票證歷程記錄。

功能隔離

功能隔離是開發隔離的特殊衍生，可讓您將一或多個 功能 分支從 主要分支，如所示，或從您的 開發 分支進行分支。

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

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

釋放隔離

發行隔離會從 main 引進一或多個發行分支。 此策略允許在發行時間進行並行發行管理、多個和平行發行，以及程式代碼基底快照集。

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

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

注意：沒有分支案例是不可變的，這就是為什麼您注意到在發行分支上執行的緊急 Hotfix。 發展每個策略以符合您的需求，而不會失去複雜度和相關聯的成本。

服務與發行隔離

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

如果您需要服務模型供客戶升級至下一個主要版本，以及每個版本的其他 Service Pack，請使用此策略。

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

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

服務、Hotfix、發行隔離

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

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

Q&A

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

藉由讓分支保持短暫存留，合併衝突會保留到盡可能少。

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

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

為什麼要移除分支？

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

程式代碼基底是否可以跨項目進行分支？

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

程式代碼升級策略呢？

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

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

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

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

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

作者：傑西·胡文、馬庫斯·費爾南德斯、邁克·福利和來自阿爾姆的威利·肖布 |DevOps Rangers。 您可以在這裡連絡他們。

（c） 2015 Microsoft Corporation. 著作權所有，並保留一切權利。 本檔提供「依目前」提供。本檔所表達的信息和檢視，包括 URL 和其他因特網網站參考，可能會變更而不通知。 您必須承擔使用本文件的風險。

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