如何禁止未通过代码评审的文件签入TFS？

当然可以！TFS（包括现在的Azure DevOps Server）完全支持强制代码评审通过后才能签入代码，甚至能根据团队需求定制严格的规则，下面给你两种最常用的实现方式：

1. 分支策略（推荐，适用于TFS 2017+ / Azure DevOps Server） #

这是当前最主流的做法，通过拉取请求（PR）机制来管控代码合并：

• 打开你的TFS项目，进入 Repos > Branches 页面
• 找到需要保护的核心分支（比如main、develop），点击分支右侧的「...」菜单，选择 Branch policies
• 在分支策略配置页，重点设置以下规则：
  • 启用 Require a minimum number of reviewers（需要最少评审人数）：
    • 勾选该选项，设置团队要求的最少批准人数（比如1人）
    • 建议勾选「Block merge until reviewers approve」，确保只有评审通过的PR才能合并到目标分支
    • 一定要开启「Prevent users from approving their own changes」，避免开发者自己评审自己的代码，失去评审意义
  • 可选：启用 Build validation，要求PR中的代码能成功编译通过，再进入评审环节，双重保障代码质量
• 配置完成后，所有向该分支提交代码的操作都必须通过PR发起，且PR必须获得指定数量的评审批准才能合并，从根源上阻止未通过评审的代码进入核心分支

2. 老版本TFS（2015及更早）的签入策略 #

如果你的TFS版本较旧，还没有PR机制，可以通过传统签入策略管控：

• 打开团队资源管理器，依次进入 Settings > Source Control > Check-in Policies
• 点击「Add」添加 Code Review Policy（代码评审策略）
• 配置策略参数：设置最少需要的评审人数、要求评审必须通过（无未解决的反对意见）等条件
• 配置完成后，开发者在签入代码前必须先发起代码评审，并获得符合要求的批准，否则TFS会直接阻止签入操作

额外注意要点 #

• 权限管控：确保只有项目管理员拥有「Bypass policies when pushing」的权限，普通用户无法绕过规则，避免有人钻空子
• 紧急场景处理：可以开启「Allow bypassing policies for urgent fixes」选项，但要严格限制使用范围，并且要求事后补做代码评审
• 自定义规则：如果团队有特殊需求（比如特定类型文件必须由特定角色评审），可以结合TFS的自定义扩展或者Azure DevOps Pipeline来实现更精细化的管控

内容的提问来源于stack exchange，提问作者Drakoo