策略性分支
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
原始碼是開發工作的重要資產。 但是，當多個開發人員同時處理檔案更新時，有效地管理及演進原始程序檔可能是一項挑戰。 您可以使用版本控制系統將原始程式碼儲存在共用存放庫中、隔離平行開發工作、整合程式代碼變更，以及復原舊版檔案。 版本控制中的關鍵元素是可同時進行開發的分支。 如果您以策略方式分支，您可以維護多個軟體版本的順序和一致性。
Team Foundation 提供彈性且可靠的版本控制系統。 您可以使用 Team Foundation 版本控制，在開發原始程式碼、檔、工作專案和其他小組處理的重要資訊期間管理多個修訂。
您的小組如何在透過數個專案版本同時導入多個變更時管理程序代碼？
當您使用版本控制系統時，必須考慮如何設定分支結構。 您可以藉由鏡像原始碼檔案來建立分支。 然後您可以變更分支，而不會影響來源。 例如，如下圖中的分支結構所示，MAIN 分支包含已完成的功能已通過整合測試，而 DEVELOPMENT 分支包含正在建構的程式代碼。 當開發分支中的新功能完成且可以通過整合測試時，您可以將程式代碼從開發分支升級至MAIN分支。 此程序稱為反向整合。 相反地，如果您將程式代碼從MAIN分支合併至開發分支，則程式稱為轉送整合。
如需如何建立和合併程序代碼分支的詳細資訊，請參閱 CodePlex 網站上的下列頁面： Team Foundation Server 分支指南 2.0。
分支和合併需要下列原則：
每個分支都必須有關於如何將程式代碼整合到此分支的已定義原則。 例如，在上圖的分支結構中，您可以指派小組成員來擁有和管理MAIN分支。 此成員負責執行初始分支作業、將開發分支的變更反向整合至MAIN分支，以及將變更從MAIN分支轉送至DEVELOPMENT分支。 當MAIN分支也整合來自其他分支的變更時，正向整合很重要。
MAIN 分支必須包含已通過整合測試的程序代碼，使其一律可供發行使用。
因為小組成員會定期簽入變更，因此開發（或工作）分支會不斷演進。
標籤是分支中檔案在特定時間的快照集。
如需詳細資訊，請參閱 使用標籤來擷取檔案的快照集。
Team Foundation Build 可讓您從數種類型的分支中選擇：手動、連續、閘道、滾動和排程。 我們建議MAIN分支具有閘道簽入組建類型。 這表示開發分支必須通過MAIN分支的所有需求，才能認可反向整合。 開發分支應該會執行持續建置類型，因為當新的簽入影響開發分支時，您的小組必須儘快知道。
您的小組應該如何反向整合和轉送整合？
如下圖所示，當您完成用戶劇本時，至少應該會發生反向整合和向前整合。 雖然每個小組可能會以不同的方式定義完整性，但完成用戶劇本通常表示您同時完成功能和對應的單元測試。 只有在單元測試已驗證 DEVELOPMENT 分支的穩定性之後，才能反向整合至 MAIN 分支。
如果您有多個工作 （DEVELOPMENT） 分支，只要任何分支整合到 MAIN 分支，就應該立即將所有工作分支轉送整合。 因為MAIN分支保持穩定，因此向前整合是安全的。 工作分支的衝突或失敗可能會發生，因為您無法保證工作分支是穩定的。
請務必儘快解決所有衝突。 藉由使用MAIN分支的閘道簽入，您可以協助讓反向整合更容易，因為品質閘道有助於避免MAIN分支中的衝突或錯誤。 如需詳細資訊，請參閱 簽入受網關簽入建置程式控制的資料夾。
您的小組如何管理實作不同用戶劇本的來源？
如下圖所示，您可以定期簽入工作分支的變更，以完成用戶劇本。 您可以同時在相同的分支中實作多個用戶劇本。 不過，只有在完成所有進行中的工作時，您才能反向整合至MAIN分支。 建議您以類似的大小將用戶劇本分組，因為您不希望大型使用者劇本封鎖許多小型案例的整合。 您可以將這兩組用戶劇本分割成兩個分支。
小組何時應該新增分支？
您應該在下列情況下建立分支：
當您必須以與現有分支不同的排程/週期發行程式代碼時。
當您的程式代碼需要不同的分支原則時。 如果您建立具有新原則的新分支，您可以將策略價值新增至專案。
當功能發行給客戶，而您的小組計劃進行不會影響計劃發行週期的變更時。
您不應該為每個用戶劇本建立分支，因為它會建立高整合成本。 雖然 TFVC 可讓分支變得容易，但如果您有許多分支，管理分支的額外負荷可能會變得相當重要。
小組如何從版本控制的觀點管理發行？
您的小組應該能夠在任何短期衝刺結束時發行程序代碼。 藉由使用Team Foundation Server，您可以為分支加上標籤，以在特定時間點建立程式碼的快照集。 如下圖所示，您可以為發行的MAIN分支加上標籤。 這可讓您此時將分支傳回其狀態。
由於您必須在發行上實作更新，因此為發行建立分支可協助小組繼續獨立處理下一個短期衝刺，而不會與未來的版本產生衝突。 下圖顯示一個分支，其中包含更新的程序代碼，並在第二個短期衝刺結束時發行后反向整合至MAIN分支。
當您建立發行的分支時，應該從MAIN分支建立該分支，這是最穩定的分支。 如果您從工作分支發行分支分支，可能會造成整合挑戰，因為工作分支的穩定性不保證。