## 1. 什麼是 Azure Repos [Azure Repos](https://azure.microsoft.com/zh-cn/services/devops/repos/?WT.mc_id=WD-MVP-5003763) 是一組版本控制工具，可用於管理程式碼。無論您的軟體專案是大型專案還是小型專案，都應儘快使用版本控制。 版本控制系統是可幫助您跟蹤隨時間變化對程式碼所做的更改的軟體。在編輯程式碼時，您告訴版本控制系統對檔案進行快照。版本控制系統會永久儲存該快照，以便以後需要時可以重新呼叫它。使用版本控制來儲存您的工作並協調整個團隊中的程式碼更改。 即使您只是一個開發人員，版本控制也可以幫助您在修復錯誤和開發新功能時保持井井有條。版本控制保留了您的開發歷史，因此您可以輕鬆檢視甚至回滾到任何版本的程式碼。 Azure Repos提供兩種型別的版本控制： - Git：分散式版本控制 - Team Foundation版本控制（TFVC）：集中式版本控制 上面是官方文件的內容。雖然給出了兩個選項，但現在大部分人都對 Git 比較熟悉，我也假設讀者對 Git 有一定了解而無需多做解釋。 ## 2. 建立專案  在上一篇文章裡我已經建立了一個專案並且選擇了 Git 作為版本控制方式，在 Azure Devops 左邊選單選中 “Files” 進入檔案頁面，首先看到的就是上圖這樣的畫面。可以看到除了剛建立的儲存庫，還可以新增新的儲存庫或匯入其它儲存庫。這篇文章我將配合最新版本的 Visual Studio 16.9 從頭開始建立專案並介紹 Azure Repos 的基本功能。 因為現有的視訊和教程幾乎都是圍繞 Azure 和 Asp.net 講解 Azure Repos 和 Pipelines，所以我特地選擇 WPF 應用來實現同樣的功能。 首先複製下面這個連結，然後開啟 Visual Studio，隨便建立一個 WPF .Net Framework 專案。  建立專案後在 Visual Studio 右下角找到“新增到原始碼管理器”按鈕，選擇“Git”。  在彈出的建立Git儲存庫對話方塊選擇“現有遠端”，在 Remote URL 中貼上剛剛複製的連結。點選建立並推送。  完成後，Visual Studio 右下角應該是這個樣子，代表現在是 wpf 儲存庫的 master 分支。  重新整理 Files 頁面，可以看到剛剛建立的專案已經上傳到 master 分支了。  ## 3. 使用策略保護分支 建立好分支後，程式碼就已經在團隊裡共享。通常來說團隊中的人都需要修改程式碼，但將程式碼提交到 master 分之前需要先通過 CodeReview。接下來將介紹如何在 Azure Repos 中通過 Branch Policies（分治策略）保護程式碼安全性。 在左側選單中選中 Branches，進入 Branches 頁面後可以看到剛剛建立的 master 分支。點選右側的”More… “按鈕，然後選擇”Brance policies“進入 master 分支的分支策略頁面。  如下圖所示，在 Branch Policies，開啟“Require a minimum number of reviewers”選項，將“Minimum number of reviewers”這是為 1，開啟“When new changes are pushed:”並選中“Reset all code reviewer votes”。  這樣設定完以後，master 分支就不能刪除，並且只能通過 Pull Request 修改；最少需要一個 Code reviewer；PR 每次發生更改都重置程式碼審閱者的投票。 下面還可以選中“Check for linked work items”，避免無緣無故的程式碼提交。 “Build Validation”涉及到 Pipelines 的內容，下一篇再解釋。 最後新增一些 Code reviewer，Optional 標識可選的，即如果有多個 Code reviewer，只需要其中一個通過就可以簽入到 master 分支。最好取消“Allow requestors to approve their own changes”。  ## 4. 通過 Pull Request 修改程式碼 假設專案裡有一個“新增單元測試”的 PBI 及它的 Task，現在我需要新增單元測試並修改一些程式碼後提交到 master 分支。但之前修改了分支策略後就不可以直接修改程式碼，而需要通過 Pull Request。  首先我需要新建分支，然後隨便更新些程式碼。然後在 Visual Studio 右下角點選這個按鈕。  在 “Git 更改” 頁面輸入提交的訊息，並且輸入 #1 #2，關聯 ID 號為 1 和 2 的工作項。然後選中“全部提交併推送”。  然後回到 Azure Devops，在左側選單選中 Pull requests，在 Pull requests 頁面可以看到系統貼心地提示我要不要建立一個 Pull request，從了它，點選“Create a pull request”。  在建立 Pull request 的頁面可以看到這個 PR 有 1 個提交併修改了 9 個檔案，系統已經貼心幫我填好 Title，並關聯了兩個工作項。點選“Create”建立完成 Pull request 的建立。  順便一提，如果標題有“[WIP]”，右下角的按鈕會預設選中“建立為草稿”。 Pull request 建立後，在 PR 的詳細頁面可以看到它的內容、是否衝突、關聯的工作項、歷史記錄等。這時候只需要等待一個 code reviewer 稽核通過，通過後右上角的藍色按鈕會變成“Complete”，點選即可完成這個 PR 並將程式碼合併到 master 分支。  也可以點選右上角的“Set auto-complete”按鈕，設定為當稽核通過後馬上自動完成。可以選中“Complete associated work items after merging”，這樣 Pull request 完成後管理的 work item （在這裡只有 Task 會自動完成，PBI 還是需要人手操作）也會被自動完成。  這時候 reviewer 會收到通知要做 review，然後他就可以來看看這個 Pull request 做了些什麼，沒問題的話他就可以 Approve 這個 Pull request。  ## 5. 最後 上面就是 Azure Repos 的基本使用方式。對屬性 Github 的開發者來說可能很容易就能上手。更多的使用方式請參考微軟提供的文件： [Azure Repos Documentation](https://docs.microsoft.com/zh-cn/azure/devops/repos/?view=azure-devops)