Azure devops “分行政策”的含义；在最后一次迭代中至少需要一次批准”；不清楚的 我们已为默认分支配置了分支策略。

我们还希望配置在推送新提交时会发生什么，以确保在完成拉请求之前正确检查新提交。有一个选项“在最后一次迭代中至少需要一次批准”。我找不到任何关于它的复杂文档。因此，我有一些问题：

这与其他可用的“重置”选项相比如何？ 这里的“最后一次迭代”是什么意思？是推送新提交之前的状态吗

---

推送新提交时，现有投票（如批准）会发生什么情况？

在分支机构策略部分，当涉及到需要多少批准以及用户是否可以批准他们自己的更改时，您可以通过多种方式配置

要求最少数量的审阅者

部分

推送新提交时，您可以在推送新更改时的

部分下选择以下选项之一


重置所有代码审阅者投票
：重置所有投票（批准、拒绝和等待）。你基本上是从头开始
重置所有批准票
：仅重置批准票。如果用户投票选择了
拒绝
或
等待
，这些评论将保持不变。如果您希望避免人们通过简单地推一个虚拟提交来绕过拒绝投票，那么这将非常有用
在最后一次迭代中至少需要一次批准
：意味着如果PR在最近一次推送之前已经满足了审查员的要求，则无论最初需要多少批准，只需要一次批准。这有助于避免与所有审核人一起开始新一轮审核，只是为了修复一些小问题或基于建议的更新，而这些建议并不是真正阻碍合并的因素
谢谢您的解释。不幸的是，这也是我从设置名称中得到的。但如果“在最后一次迭代中至少需要一次批准”，则只需要一次批准，这对已设置的批准意味着什么？它们是否全部重置，或者是否引入了一种二级批准类型？我真的希望这个设置的文档更全面。用例：3名评审员均已批准，但PR未完成。现在是新的承诺。现在会发生什么？因为在推送最后一次提交之前，已经满足了最低审批人（假设是三个）的要求，所以在合并之前只需要一个审阅者。如果您想再次要求所有3个项目进行审批，您应该这样做。选择
重置所有代码审阅者投票
或
重置所有批准投票
。如果您选择“在上一次迭代中至少需要一次批准”

，则不会重置投票，但您需要一次额外的“接受投票”，然后才能合并投票。这个额外的接受投票可以来自3个最初的批准人之一，他们只是再次投票接受。现在很清楚了。非常感谢。