2016年12月7日在GitHub博客上发布的一项功能,推出了选项to add reviewers to a Pull Request
您现在可以从协作者处明确请求审核,从而可以更轻松地指定您要审核拉取请求的人。
您还可以在拉取请求页面边栏中查看正在等待审核的人员列表,以及已经离开他们的人员的评论状态。
但是,已经通过分配人员(受让人选项)明确设置PR的审阅者。
现在有两个选项,每个选项的作用是什么,因为它们都有相同的最终目标?
答案 0 :(得分:91)
修改强>
在与几位OSS维护人员讨论后,审稿人被定义为该词应该是什么:审查(某人的代码)和“受让人”有一个更宽松的定义,如下所述。
对于“评论者”:您要查看代码的人。不一定是负责该区域或负责合并提交的人员。可能是之前处理过那段代码的人,正如GitHub自动建议的那样。
对于“受让人”:由项目的团队/维护者决定它的含义并没有严格的定义。它可以是公关揭幕战,也可以是负责该领域的人(在审查完成后将接受公关或仅关闭公关)。 GitHub无法定义它为项目维护人员开放的最适合他们项目的内容。
上一个回答:
好的,我会继续回答我自己的问题。
对于具有写访问权限的用户的公关:受让人将是打开公关的同一人,审核人将替换旧的受让人功能(审查代码),这是受让人之一选择。
对于没有写访问权限的用户的PR(外部贡献者):具有写访问权限的人将为自己(或其他写权限成员)分配,以审查PR(审阅者)。受让人是空白的。
对于来自外部贡献者的未完成的公关:写访问成员将完成未完成的工作并为她分配。她将负责完成任务,成为受让人。由于PR的主要原因是审查变更,她会选择其他人来审查变更。
答案 1 :(得分:19)
在GitHub中,审阅者是审查提取请求的人。项目所有者可以请求任何维护者进行审核。他们甚至可以设置一个选项,以便只有在具有写访问权限的维护者之一审核了拉取请求时才能合并拉取请求。
根据官方github documentation,受让人是处理特定问题和提出请求的人。它有时被混淆为评论者。它实际上是用于问题而不是拉取请求,以便当我们收到问题时,我们可以指派某人来修复它。在拉取请求中,受让人是指在获得评论和更改其他维护者的请求后负责合并该拉取请求的人。
答案 2 :(得分:11)
根据接受的答案。是的,“受让人”有一个更宽松的定义,可以不同的方式使用,以满足团队的需要。
在我们的8个开发团队中,在大多数PR中,我们有1个评论员,他们建议进行更改并最终批准PR。在审查阶段,“受让人”是开设公关的人;稍后,如果PR被其他开发人员接收,则会添加新的“受让人”。一旦PR获得批准并准备好进行质量保证或直接合并,就会增加一个新的质量保证“受让人”。这样“受让人”名单就会增长。
我们使用“受让人”集体指定下列人员:
答案 3 :(得分:3)
“审稿人”和“受让人”之间的最大区别在于,审稿人实际上根据 GitHub 具有跟踪状态——他们是否审阅了 PR?
当您添加审阅者时,它实际上所做的是创建一个"review request":
审阅者会收到通知(就像“受让人”一样),但现在他们实际上有一项可以完成的任务,即在拉取请求中提供 "review":
在审核者留下审核(批准或请求更改)后,该信息会在 GitHub API 和界面中进行跟踪:
对于受让人,您可以将人员与 PR 联系起来,但除此之外,GitHub 并不真正关心这意味着什么或这些人需要做什么。对于审阅者,您可以使用 new search queries、"protect" branches,使用 CODEOWNERS 和 build deeper API integrations around review assignment and workflows manually or through tools like PullApprove 分配审阅者。
答案 4 :(得分:1)
在GitHub之前,只有受让人字段,而没有审阅者字段。当时没有区别,因此受让人字段通常用作审阅者字段。
但是请以适合您项目的任何方式使用它们。
答案 5 :(得分:0)
另一个区别:PR的创建者可以将自己指定为受让人,但不能将自己指定为审稿人之一。