GitHub评审里的pending、Viewed与Comment：三种记录为何不能合成“已批准”

一个拉取请求旁边已经有评论，还能不能把它写成“评审已批准”？GitHub的Reviewing proposed changes说明要求更具体地看评论处于什么阶段、文件是否只是被标为已看，以及提交评审时选择了哪一种反馈。[1] 这些记录都与review有关，却没有共同代表同一项批准结论。

行评论首先可能处于pending状态。官方说，在提交整份评审之前，这些评论只对评审者本人可见，并且可以继续编辑。[1] 因此，写下意见与把意见提交给协作者之间，还有一个明确阶段。只有评论草稿存在，并不能在交接中直接说其他人已经收到相同反馈；这里的可见性条件是原文规则，不是本次检查了任何私人拉取请求。

文件的Viewed标记表达另一种进度。文档说，文件被标为已看后会折叠，便于跟踪阅读；如果该文件随后发生改变，标记会被取消。[1] 这使Viewed与所看文件版本之间具有联系。它不是把一个路径永远宣布成已完成，也没有独自说明评审者对改动做出了哪一种判断。

可以用一个没有真实仓库的情境理解：某人已看过文件甲，留下的行意见仍为pending，随后作者又改了甲。按上述说明，阅读标记和评论提交各有自己的状态关系。[1] 不能只保留“甲看过了”这句话，就替当前内容补出已批准结论。这个分析用于区分协作记录，没有发送评论或操作文件标记。

提交review时的反馈类型又有明确语义。Comment用于一般反馈，不显式批准改动，也不要求额外修改；Approve用于提交反馈并表达批准合并所提改动；Request changes则表达需处理修改的反馈。[1] 三者不能只按“都留了文字”来合并，概括反馈的类型本身是理解意见的重要部分。

本篇不把Request changes扩大成任何仓库都被技术性禁止合并。原页在相邻提示中另附规则集或分支保护条件；因此，反馈类型与平台是否强制阻止合并，应按各自说明理解。[1] 这里保留的是措辞范围，没有变更保护规则、权限或任何合并安排。

把这几层联系起来，资料中的“完成”就能说得更准确：pending描述尚未提交的行意见，Viewed记录具体文件的阅读进度，提交后的类型表达一般反馈、批准或要求修改。它们分别回答反馈是否提交、哪些文件被看过、评审表达什么立场，不能由一个评论数或一个已看标记代填全部答案。

采用的是GitHub.com公开帮助的连续说明与必要邻接，首次发布日期未确认。本文没有读取私人项目、提交评审、改变权限或验证代码测试结果；所解释的只是平台协作记录的语义，不把批准类型当作改动已经修复问题或已完成合并的证明。

资料：[1] https://docs.github.com/en/pull-requests/how-tos/review-pull-requests/reviewing-proposed-changes-in-a-pull-request