關於分支和分支原則
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
分支原則是 Git 工作流程的重要部分，可讓您：
- 將進行中的工作與主要分支中已完成的工作隔離
- 保證在變更進入主分支之前成功建置
- 限制誰可以參與特定分支
- 強制執行誰可以建立分支和分支的命名指導方針
- 自動為每個程式碼變更包含正確的審查者
- 使用必要的程式碼審閱者落實最佳做法
下表總結了您可以定義以自訂分支的政策。 如需所有存放庫和分支原則和設定的概觀，請參閱 Git 存放庫設定和原則。
原則
預設值
說明
關閉
在提取要求上，需要指定數目的檢閱者核准。
關閉
檢查提取要求上是否有連結的工作專案，以鼓勵可追蹤性。
關閉
檢查合併請求中的所有評論是否已解決。
關閉
藉由限制提取要求完成時可用的合併類型來控制分支歷程記錄。
關閉
新增一或多個原則，藉由預先合併和建置提取要求變更來驗證程序代碼。 也可以啟用或停用政策。
關閉
新增一或多個原則，以要求其他服務張貼成功狀態以完成提取要求。 也可以啟用或停用政策。
關閉
新增一個或多個政策，指定程式碼審核者，在拉取請求變更特定程式碼區域時自動包含。 也可以啟用或停用政策。
採用 Git 分支策略
您的存放庫中有一些重要的分支，小組一直仰賴其狀態良好，例如您的 main 分支。
需要拉取請求 才能在這些分支上進行任何變更。 將變更直接推送至受保護分支的開發人員將會拒絕其推送。
透過從下列三個概念建置策略，讓您的分支策略保持簡單：
- 所有新功能和 Bug 修正均需使用功能分支。
- 使用拉取請求將功能分支合併至主要分支。
- 保持高品質的 up-to-date 主分支。
擴充這些概念並避免矛盾的策略，會導致小組的版本控制工作流程一致且容易遵循。
在分支中創建工作項目
Git 分支不過就是一個保留提交記錄的小型參考，因此它們很容易創建。
把 變更提交到一個分支不會影響其他分支。 您可以與其他人共用分支，而不需要將變更合併至主要專案。
您可以建立新分支，將功能或錯誤修復的變更與主分支和其他工作隔離開來。
由於分支是輕量型的，因此在分支之間切換是快速且容易的。 使用分支時，Git 不會建立原始檔案的多個複本，而是會利用儲存在提交中的歷程記錄資訊，在開始處理分支時在分支中還原檔案。
您的 Git 工作流程 應該建立和使用分支來管理功能和 Bug 修正。
Git 工作流程的其餘部分，例如 共用程式代碼，以及 檢閱具有提取要求的程式代碼， 透過分支運作。
在分支中隔離工作可讓您輕鬆地透過切換當前的分支來變更您正在處理的工作。
如何建立 Git 分支？
您可以使用 branch 命令建立分支。
Branch 在 Git 中為新分支建立參考，並將指標指向父認可，讓 Git 可以在您將認可新增至分支時保留變更的歷程記錄。
當您使用其他人分享的分支時，Git 會保留與上游的追蹤關係。 關聯性會將本機存放庫上的分支與遠端存放庫上的對應分支產生關聯。
在此螢幕快照中，您可以看到從主要分支建立的新分支。 在兩個分支上繼續工作，並且提交會新增至這兩個分支。
Git 會將新的提交新增至目前的本機分支。 提交變更之前，請先確認您正在操作的分支，避免將變更提交到錯誤的分支。
使用 checkout 命令在本機分支之間切換。 Git 會變更你電腦上的檔案，使其符合已檢出分支上的最新提交。
當您在分支中的工作已準備好與小組的其餘人員共用時，推送 變更以更新遠端分支。
常見的錯誤是進行一些變更，並 commit 變更，發現您位於不正確的分支上，然後 checkout 正確的分支。
您最近的變更將不再位於文件系統上，因為每個分支都有自己的程式碼版本。
Git 會將檔案的狀態帶回您切換到的分支的最後一次提交，而不是您進行更改的之前所在分支。
使用分支來管理開發
Git 會追蹤您正在處理的分支，並確定當您 checkout 分支時，您的檔案符合分支上最新的認可。
分支可讓您同時在同一個本機 Git 存放庫中使用多個版本的原始程式碼。
使用 checkout告訴 Git 您要處理哪個分支，Git 會自動為該分支設定正確的檔案版本。
當您使用分支來隔離工作時，您的系統上不需要多個存放庫。
在您 複製之後，請設定開發環境一次。 然後，使用 Git 分支在功能開發與修正錯誤之間切換。
分支操作指南
瞭解如何在處理分支時完成常見任務。