练习与拉取请求协作的 Azure Repos
越早发现的代码问题越易于修复，并且修复成本越低。 因此，开发团队努力将代码质量检查尽可能早地纳入开发过程中。
顾名思义，分支策略为你提供了一组现成的策略，这些策略可应用于服务器上的分支。
任何推送到服务器分支的更改都需要遵循这些策略，然后才能接受更改。
通过这些策略可以强制实施团队的代码质量和更改管理标准。 在本方案中，你将了解如何在主分支上配置分支策略。
做好准备
现成的分支策略包含多个策略，例如生成验证和强制实施合并策略。 我们将仅关注在本方案中设置代码评审工作流所需的分支策略。
如何实现
在 Parts Unlimited 团队门户中打开 myWebApp Git 存储库的分支视图。 选择主分支，然后从下拉的上下文菜单中选择分支策略：
在策略视图中，它显示现成的策略。 将审阅者的人数下限设置为 1：
通过“允许请求者审批自己的更改”选项，提交者可自行审批其更改。
虽然对于成熟的团队来说，这也许可以接受，但一般来说，应该避免这样做。
将评审策略与注释解决策略搭配使用。 这样，你就能强制要求在接受更改之前解决代码评审注释。 请求者可从注释中获取反馈，并创建新的工作项和解决所做的更改。 这样至少保证了随着代码被接受进入主分支，代码评审注释不会丢失：
要求促使在团队项目中进行代码更改。 如果触发工作的工作项没有链接到更改，那么随着时间的推移，就很难理解为什么要进行更改。 在查看更改历史记录时，这种链接特别有用。 配置“查看链接工作项”策略，以阻止没有链接到工作项的更改：
选中用于在自动引发拉取请求时自动包括审阅者的选项。 可以根据要更改的代码区域来映射要添加的审阅者：
工作原理
实施分支策略后，主分支现在受到全面的保护。
将更改推送到主分支的唯一方法是先在另一个分支中进行更改，然后引发拉取请求以触发更改验收工作流。
选择从工作项中心的现有用户情景之一创建新分支。
通过从工作项创建新分支，该工作项会自动链接到该分支。
在创建工作流的过程中，可以选择包括多个具有分支的工作项：
创建分支时在名称中添加前缀，来创建一个文件夹便于保存分支。
在上一示例中，分支将放入到文件夹中。 这样就能在繁忙环境中整理分支。
在 Web 门户中选择了新创建的分支后，编辑 HomeController.cs 文件以包含以下代码片段，并提交对分支所做的更改。
在下图中，你将看到编辑文件后可通过单击“提交”按钮直接提交更改。
团队门户中的文件路径控件支持搜索。
开始键入文件路径以查看该目录下 Git 存储库中的所有文件，从文件路径搜索结果下拉列表中显示的这些字母开始。
Web 门户中的代码编辑器新增了几项 Azure DevOps Server 中的功能，例如支持括号匹配和切换空格。
可以按下命令面板来加载它。 在许多其他新选项中，你现在可以使用文件缩略图、折叠和展开以及其他标准操作来切换文件。
若要将这些更改从新分支推送到主分支，请从拉取请求视图创建拉取请求。
选择新分支作为源，选择主分支作为目标分支。
新的拉取请求窗体支持 Markdown，因此你可以使用 Markdown 语法添加说明。
“说明”窗口还支持 @ 用于提及和 # 用于链接工作项：
拉取请求已创建；概述页面汇总了更改和策略的状态。
“文件”选项卡显示更改列表，以及以前版本与当前版本的差异。
推送到代码文件的任何更新都会显示在“更新”选项卡中，所有提交的列表显示在“提交”选项卡下：
打开“文件”选项卡：此视图支持行级别、文件级别和整体的代码注释。
注释支持 @ 用于提及和 # 用于链接工作项，文本支持 Markdown 语法：
代码注释保留在拉取请求工作流中；代码注释支持多次迭代评审，并且可与嵌套响应很好地搭配。
审阅者策略允许代码评审工作流作为更改接受的一部分。
这是团队协作处理推送到主分支的任何代码更改的极佳方法。
当所需数量的审阅者批准拉取请求时，该请求就可完成。
还可以将拉取请求标记为在评审后自动完成。 成功编译所有策略后，将自动完成拉取请求。
还有更多内容
是否遇到过分支被意外删除的情况？ 要弄清楚发生了什么并不容易。
Azure DevOps Server 现在支持搜索已删除的分支。 你可以用它来了解删除它的人员和时间。 利用该接口还可以重新创建分支。
只有在按已删除分支的确切名称搜索时（消除搜索结果中的干扰），才会显示已删除的分支。
若要搜索已删除的分支，请在分支搜索框中输入完整的分支名称。 这将返回与搜索文本匹配的全部现有分支。
你还会看到一个选项，用于搜索已删除分支列表中的完全匹配项。
如果找到匹配项，你就能看到删除它的人员和时间。 你还可以还原分支。 如果还原此分支，将在它最后指向的提交中重新创建它。
但是，无法还原策略和权限。