Azure DevOps 服務 |Azure DevOps Server |Azure DevOps Server 2022
像 Git 這樣的分散式版本控制系統可讓您靈活地使用版本控制來共用和管理程式碼。 您的團隊應該在這種靈活性與以一致的方式協作和共享代碼的需求之間找到平衡。
團隊成員透過與他人共用的 Git 分支發佈、共用、檢閱和反覆專案變更。 為您的團隊採用分支策略。 您可以更好地協作，花更少的時間管理版本控制，將更多的時間花在開發程式碼上。
下列分支策略是以我們在 Microsoft 使用 Git 的方式為基礎。 如需詳細資訊，請參閱 Microsoft 如何使用 Git。
讓您的分支策略保持簡單
保持分支策略簡單。 根據以下三個概念制定您的策略：
- 使用功能分支來修正所有新功能和錯誤修正。
- 使用提取要求將功能分支合併到主要分支中。
- 保持高品質、up-to日期的主要分支。
擴展這些概念並避免矛盾的策略將為您的團隊帶來一致且易於遵循的版本控制工作流程。
針對您的工作使用功能分支
開發您的功能，並根據您的主要分支修正功能分支中的錯誤。 這些分支也稱為 主題分支。 功能分支會將進行中的工作與主要分支中的已完成工作隔離。 Git 分支的建立和維護成本低廉。 即使是小的修復和更改也應該有自己的功能分支。
為所有變更建立功能分支，讓檢閱歷程記錄變得簡單。 查看分支中所做的提交，並查看合併分支的拉取請求。
依慣例命名您的功能分支
針對功能分支使用一致的命名慣例，以識別分支中完成的工作。 您也可以在分支名稱中包含其他資訊，例如分支的建立者。
命名功能分支的一些建議：
- 用戶/用戶名/描述
- 使用者/使用者名稱/工作項目
- 錯誤修復/描述
- 功能/功能名稱
- 功能/功能區域/功能名稱
- 熱修復/說明
備註
如需設定原則以強制執行分支命名策略的資訊，請參閱 需要分支資料夾。
使用功能旗標來管理長時間執行的分支
深入瞭解如何在程式碼中使用 功能旗標 。
檢閱並合併程式碼與提取要求
在提取請求中進行的審查對於提高程式碼品質至關重要。 僅透過通過檢閱程式的提取要求合併分支。 避免在沒有提取請求的情況下將分支合併到主分支。
提取要求中的檢閱需要一些時間才能完成。 您的小組應該同意提取要求建立者和檢閱者的預期。 分配審閱者的職責，以在整個團隊中分享想法並傳播程式碼庫的知識。
一些成功拉取請求的建議：
- 根據 研究，兩名審稿人是最佳數字。
- 如果您的小組已經有程式碼檢閱程式，請將提取要求帶入您已經在執行的作業中。
- 請小心將相同的檢閱者指派給大量提取要求。 當檢閱者職責在整個團隊中分擔時，提取請求會運作得更好。
- 在描述中提供足夠的詳細資訊，讓檢閱者快速了解您的變更。
- 在提取請求中包含在暫存環境中執行的變更的組建或連結版本。 其他人可以輕鬆測試這些變化。
保持高品質、up-to日期的主分支
主分支中的程式碼應該通過測試、乾淨地建置，並且始終是最新的。 您的主要分支需要這些品質，以便小組建立的功能分支從已知的良好程式碼版本開始。
為您的主要分支設定 分支原則 ，以：
- 需要提取請求才能合併程式碼。 這種方法可以防止直接推送到主分支，並確保討論提議的變更。
- 建立提取要求時自動新增檢閱者。 新增的小組成員會檢閱程式碼，並註解提取要求中的變更。
- 需要成功的建置才能完成提取請求。 合併到主分支的程式碼應該可以乾淨地建置。
小提示
提取請求的建置管線應該可以快速完成，因此不會干擾檢閱程式。
管理發佈版本
使用發行分支來協調和穩定程式碼發行中的變更。 此分支是長期存在的，而且不會合併回提取要求中的主要分支，這與功能分支不同。 視需要建立任意數量的發行分支。 請記住，每個作用中的發行分支都代表您需要支援的程式碼的另一個版本。 當您準備好停止支援特定版本時，鎖定發行分支。
使用發行分支
當您接近發行或其他里程碑 （例如短期衝刺結束） 時，從主要分支建立發行分支。 為此分支提供明確的名稱，將其與版本相關聯，例如 release/20。
建立分支以修正發行分支中的錯誤，並將它們合併回提取要求中的發行分支。
埠變更回主分支
請確定修正程式同時位於您的發行分支和主要分支中。 一種方法是在發行分支中進行修正，然後將變更帶入主分支，以防止程式碼回歸。 另一種方法 （以及 Azure DevOps 小組所採用的方法） ，是一律在主線中進行變更，然後將這些變更移植到發行分支。 您可以閱讀有關我們的 發行流程 策略的更多資訊。
在本主題中，我們將介紹如何在發行分支中進行變更，並將其移植到主線。 使用櫻桃挑選而不是合併，以便您可以精確控制哪些提交移植回主分支。 將發行分支合併到主要分支中，可以帶來您不想要在主要分支中進行發行專屬的變更。
使用下列步驟，使用發行分支中所做的變更來更新主要分支：
- 從主要分支建立新的功能分支，以移植變更。
- 挑選從發行分支到新功能分支的變更。
- 將功能分支合併回第二個提取要求中的主要分支。
此發行分支工作流程會保持基本工作流程的支柱不變：功能分支、提取要求，以及一律擁有最新版本程式碼的強式主要分支。
為什麼不使用標籤來發布？
其他分支工作流程會使用 Git 標籤 ，將特定認可標記為發行。 標籤對於將歷史記錄中的點標記為重要點非常有用。 標籤會在工作流程中引入額外的步驟，如果您使用分支進行發行，則不需要這些步驟。
標籤會與您的提交分開維護和推送。 團隊成員很容易錯過標記提交，然後必須返回歷史記錄來修復標籤。 您也可以忘記推送標籤的額外步驟，讓下一個開發人員在支援版本時使用舊版本的程式碼。
發行分支策略會擴充基本功能分支工作流程，以處理發行。 您的團隊不需要採用任何新的版本控制流程，除了挑選移植變更之外。
管理部署
您可以處理多個版本的方式處理程式碼的多個部署。 建立清楚的命名慣例，例如 deploy/performance-test，並將環境分支視為發行分支。 您的小組應該同意使用主要分支的程式碼更新部署分支的程式。 將部署分支中的錯誤修正挑回主分支。 使用與從發行分支移植變更相同的步驟。
此建議的例外狀況是您使用持續部署的形式。 使用持續部署時，請使用 Azure Pipelines ，將組建從主要分支升級至部署目標。