在GitHub上,评论者和受让人之间有什么区别？

Question

2016年12月7日在GitHub博客上发布的一项功能介绍了将评论者添加到Pull Request的选项

您现在可以从协作者明确请求审核,从而更轻松地指定您要审核拉取请求的人员.

您还可以在拉取请求页面边栏中查看正在等待审核的人员列表,以及已经离开他们的人员的评论状态.

但是,通过分配人员(受让人选项)已经完成了为PR进行明确设置审阅者的工作.

现在有两个选项,每个选项的作用是什么,因为它们都有相同的最终目标？

Answer 1

编辑:

在与几个OSS维护者讨论之后,评论者被定义为该词应该是什么:审查(某人的代码)和"受让人"有一个更宽松的定义,如下所述.

对于"评论者":您想要查看代码的人.不一定是负责该区域或负责合并提交的人员.正如GitHub自动建议的那样,可能是之前处理过这段代码的人.

对于"受让人":对项目的团队/维护者来说意味着什么,并没有严格的定义.它可以是公关揭幕战,也可以是负责该领域的人(在审查完成后将接受公关或仅关闭公关).GitHub无法定义它为项目维护人员打开什么最适合他们项目的东西.

上一个答案:

好的,我会继续回答我自己的问题.

对于具有写访问权限的用户的PR:受让人将是打开PR的同一人,审阅者将替换旧的受让人功能(审查代码),这是受让人选择的人.

对于没有写访问权限的用户的PR(外部贡献者):具有写访问权限的人将分配自己(或其他写权限成员),以审查PR(审阅者).受让人是空白的.

对于来自外部贡献者的未完成的PR:写访问成员将完成未完成的工作并为她分配.作为受让人,她将负责完成任务.由于PR的主要原因是审查变更,她会选择其他人来审查变更.

Answer 2

在GitHub中,审阅者是审查提取请求的人.项目所有者可以请求任何维护者进行审核,他们甚至可以设置一个选项,以便只有在具有写访问权限的维护者之一审核了拉取请求时才能合并拉取请求.

根据官方github文档,受让人是一个正在处理特定问题和提出请求的人.它有时被混淆为评论者.它实际上是用于问题而不是拉取请求,以便当我们收到问题时,我们可以指派某人来修复它.在拉取请求中,受让人是指在获得评论和更改其他维护者的请求后负责合并该拉取请求的人.

Answer 3

“审阅者”和“受让人”之间最大的区别在于，根据 GitHub，审阅者实际上有一个跟踪状态——他们是否审阅了 PR？

当您添加审阅者时，它实际上所做的是创建“审阅请求”：

审阅者会收到通知（就像“受让人”一样），但现在他们实际上有一个可以完成的任务，即对拉取请求 提供“审阅” ：

审阅者留下审阅（批准或请求更改）后，将在GitHub API和界面中跟踪该信息：

对于受让人，您可以将人员与 PR 联系起来，但除此之外，GitHub 并不真正关心这意味着什么或这些人需要做什么。通过审阅者，您可以使用新的搜索查询、“保护”分支、使用CODEOWNERS分配审阅者，并手动或通过 PullApprove 等工具围绕审阅分配和工作流程构建更深入的 API 集成。

Answer 4

按照接受的答案.是的,"受让人"有一个更宽松的定义,可以不同的方式使用,以满足团队的需要.

在我们的8个开发团队中,在大多数PR中,我们有1个评论员,他们建议进行更改并最终批准PR.在审查阶段,"受让人"是开设公关的人; 稍后,如果PR被其他开发人员接收,则会添加新的"受让人".一旦PR获得批准并准备好进行质量保证或直接合并,就会增加一个新的质量保证"受让人".这种方式"受让人"名单增长.

我们使用"受让人"集体指定下列人员:

1. 拉请求作者
2. 致力于公关改变建议的作者(通常与1相同)
3. QA参与的人
4. 负责合并的人(通常与2或3相同)

使用"受让人"有助于将来轻松定位PR.我的一个项目有> 3000 PRs.

is:open is:pr author:raya-dumas

is:closed is:pr assignee:raya-dumas

或者只是author:raya-dumas找到作者创建的所有项目(问题,PR)

和其他类似的查询,以简化搜索过程."里程碑"对于使用以及简化PR搜索非常有帮助.