关于分支策略“Require at least one approval at the last iteration”的技术咨询

我来帮你拆解这个分支策略选项的细节，刚好对这块比较熟悉：

常见的「Reset」类选项（比如“Reset approvals when new commits are pushed”）逻辑很直接：只要你往PR里推送新的commit，所有已有的审批（Approve/Reject）都会被直接清空，评审人必须重新发起审批操作。

而「Require at least one approval at the last iteration」的逻辑更灵活：它不会清空历史审批记录，但合并PR时只认最后一次迭代阶段内的审批——也就是说，历史上的审批不算数，必须在最新的代码版本上完成至少一次有效审批。

这里的「iteration」可以理解为PR的一个“代码版本周期”：

• 当你创建PR时，第一个迭代就启动了；
• 每当你往这个PR推送新的commit（不管是追加、变基还是替换），就会结束当前迭代，开启一个新的迭代；
• 「last iteration」就是指最新的那个代码版本对应的迭代阶段——也就是你最后一次推送commit之后的PR状态，绝对不是推送前的旧状态。

举个例子：你先推了v1版本的代码到PR，评审人A审批通过；之后你又推了v2版本修复bug，这时候就开启了新的迭代，「last iteration」就是v2版本对应的阶段，之前v1的审批不算数。

当你推送新commit时，已有的投票（比如之前的Approve/Reject）会被保留在PR的历史记录里，但系统在检查合并条件时会忽略这些历史投票，只看新迭代（也就是新commit推送后）是否有至少一次有效的Approval。

简单说：之前的审批记录还能看到，但不算数了，必须让评审人针对最新的代码重新做一次审批操作，才能满足合并要求。

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