在GitHub上,审稿人和受让人有什么区别?

在GitHub博客上发布的2016年12月7日添加的function介绍了将审阅者添加到合并请求的选项

GitHub评论选项

您现在可以向协作者明确请求审核,以便更轻松地指定要查看您的拉取请求的人员。

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

但是,明确设定公关评论者的做法已经通过分配人员( 受让人选项)完成。

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

编辑:

在与几位OSS维护人员讨论之后, 评审人员被定义为这个词应该是什么:审查(某人的代码)和“受让人”有一个更宽松的定义,下面解释。

对于“审阅者” :您想要查看代码的人。 不一定是负责该区域或负责合并提交的人员。 就像GitHub自动build议的那样,可能是之前编写过这段代码的人。

对于“受让人” :直到项目的团队/维护者意味着什么,没有严格的定义。 它可以是公关开幕人,也可以是负责该领域的人(审查结束后或接近公关的人)。 GitHub并没有定义它为项目维护者开放的东西,哪些项目最适合他们。

先前的回答:

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

对于写访问权限的用户,受让人是开放公关的同一个人,审核人将代替原受让人的function(审核代码),这是受让人select的人。

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

对于来自外部贡献者的未完成的公共关系 :写入访问成员将完成未完成的工作并为其指定。 她将负责完成任务,成为受让人 。 由于PR的主要原因是审查变化,她会select其他人来审查变化。

在GitHub中,评论者是审查拉取请求的人。 项目所有者可以向任何维护人员请求审阅,他们甚至可以设置一个选项,以便拉取请求只有在具有写权限的维护人员审阅时才能合并。

根据github官方文档 ,Assignee是一个正在处理特定问题并提出请求的人。 有时作为审稿人混淆。 它实际上是用来解决问题,而不是拉请求,所以当我们收到问题时,我们可以指派一个人来解决问题。 在拉取请求中,受让人是指在收到其他维护人员的评论和更改请求后,负责合并该拉取请求的人员。