練習 Azure Repos 與提取要求共同作業
較快發現的程式代碼問題既容易又便宜，可修正。 因此，開發小組會盡量將程式碼品質檢查早期推進至開發過程。
顧名思義，分支政策提供一組預設的政策，可以套用到伺服器上的分支。
任何推送至伺服器分支的變更都必須遵循這些原則，才能接受變更。
政策是實施團隊程式碼質量和變更管理標準的絕佳方式。 在此教程中，您將瞭解如何在主要分支上設定分支原則。
做好準備
現成的分支原則包含數個原則，例如建置驗證並強制執行合併策略。 我們只會專注於在此配方中設定程式碼檢閱工作流程所需的分支原則。
如何執行
在不受元件限制的小組入口網站中開啟 myWebApp Git 存放庫的分支檢視。 選取主要分支，然後在下拉式功能表中選擇 [分支原則]。
在 [原則] 檢視中，它呈現預設的原則。 將檢閱者數目下限設定為 1：
[允許要求者核准自己的變更] 選項可讓提交者自行核准其變更。
雖然對於成熟的團隊來說，這也許可以接受，但一般而言，應該避免。
使用檢閱政策搭配批註解決政策。 它允許您強制在接受變更之前，先解決程式碼審查中的批注。 要求者可以從批注取得意見反應，並建立新的工作專案並解決變更。 至少可以確保程式檢閱批註在程式碼被接受進入主要分支後不會遺失。
需求會引發團隊專案中的程式代碼修改。 如果觸發工作的工作項目未連結至變更，隨著時間的推移，很難理解它為何被做出。 檢閱變更歷程記錄時特別有用。 設定檢查連結的工作項目原則，以封鎖沒有連結工作項目的變更：
選取選項，在自動引發提取要求時自動包含檢閱者。 您可以根據變更的程式代碼區域來對應新增的檢閱者：
運作方式
有了分支原則，主要分支現在會受到完全保護。
將變更推送至主要分支的唯一方法是先在另一個分支中進行變更，然後引發提取要求以觸發變更接受工作流程。
選擇從工作項目集中區的其中一個現有使用者故事建立新的分支。
從工作專案建立新的分支，該工作專案會自動連結至分支。
您可以選擇性地在建立工作流程中包含多個具有分支的工作專案：
在建立分支時，請在名稱中加入前置詞，以便將分支歸入一個資料夾中。
在上述範例中，分支將會移至 資料夾中。 這是在忙碌環境中組織分支的絕佳方式。
在網頁入口選取新建立的分支後，編輯 HomeController.cs 檔案以包含下列程式碼片段，並將變更提交至該分支。
在下圖中，您會看到您可以按下 [認可] 按鈕，在編輯檔案之後直接認可變更。
小組入口網站中的檔案路徑控制項支援搜尋。
開始輸入檔案路徑，以查看該目錄下 Git 存放庫中的所有檔案，從檔案路徑搜尋結果下拉式清單中顯示這些字母開始。
入口網站中的程式代碼編輯器在 Azure DevOps Server 中有數項新功能，例如支援括弧比對和切換空格符。
您可以按下對應的鍵以載入命令選擇區。 在許多其他新選項中，您現在可以使用檔案縮略圖、折疊和展開功能，以及其他標準操作來切換檔案。
若要將這些變更從新分支推送至主要分支，請從提取要求檢視建立提取要求。
選取新的分支作為來源，並將main選取為目標分支。
新的提取要求表單支援 Markdown，因此您可以使用 Markdown 語法來新增描述。
描述視窗也支援 @ 提及與 # 連結工作專案：
建立拉取請求，概覽頁面總結方針的變更和狀態。
[檔案] 索引標籤會顯示變更清單，以及舊版與目前版本之間的差異。
推送至程式碼檔案的任何更新都會顯示在 [更新] 標籤中，且所有提交的列表會顯示在 [提交] 標籤下：
開啟 [檔案] 索引標籤：此檢視支援行層級、檔案層級和整體的程式代碼批註。
批注同時支援 @ 表示提及和 # 連結工作專案，而文字支援 Markdown 語法：
程序代碼批注會保存在拉取請求流程中，程序代碼批注支持多次檢閱反覆，並且相容於嵌套回應。
檢閱者原則允許程式代碼檢閱工作流程作為變更接受的一部分。
對於推送至主要分支的任何程式碼變更，這對小組合作而言是個很好的方式。
當所需的檢閱者數目核准提取要求時，即可完成。
您也可以在審查後，將拉取請求標示為自動完成。 一旦成功編譯所有原則，它就會自動完成提取要求。
還有更多
您是否曾處於意外刪除分支的狀態？ 很難弄清楚發生了什麼事。
Azure DevOps Server 現在支援搜尋已刪除的分支。 它可協助您瞭解誰刪除了它，以及何時刪除。 介面也可讓您重新建立分支。
只有在您依其確切名稱搜尋已刪除的分支，以從搜尋結果中減少雜訊時，才會顯示這些分支。
若要搜尋已刪除的分支，請在分支搜尋方塊中輸入完整分支名稱。 它會傳回任何符合該文字的現有分支。
在已刪除的分支清單中，您也會看到精確匹配搜尋的選項。
如果找到相符專案，您會看到誰刪除了它，以及何時刪除。 您也可以還原分支。 還原分支將會在最後一個指向的認可時重新建立它。
不過，它不會還原原則和許可權。