[Azure DevOps] 使用 Azure Repos 管理代码

1. 什么是 Azure Repos

Azure Repos 是一组版本控制工具，可用于管理代码。无论您的软件项目是大型项目还是小型项目，都应尽快使用版本控制。

版本控制系统是可帮助您跟踪随时间变化对代码所做的更改的软件。在编辑代码时，您告诉版本控制系统对文件进行快照。版本控制系统会永久保存该快照，以便以后需要时可以重新调用它。使用版本控制来保存您的工作并协调整个团队中的代码更改。

即使您只是一个开发人员，版本控制也可以帮助您在修复错误和开发新功能时保持井井有条。版本控制保留了您的开发历史，因此您可以轻松查看甚至回滚到任何版本的代码。

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 的开发者来说可能很容易就能上手。更多的使用方式请参考微软提供的文档：