根据接受的答案。是的，“受让人”的定义比较宽松，可以根据不同团队的需要进行不同的使用。

在我们由8名开发者组成的团队中，大多数PR都有1名审查员，他负责提出修改建议并最终批准PR。在审查员阶段，“受让人”是打开PR的人;之后，如果PR被其他开发者接手，就会增加一个新的“受让人”。一旦PR被批准并准备好进行QA或直接合并，就会添加一个新的QA“受让人”。这样“受让人”列表就会增加。

我们用“受让人”来统称下列人员:

拉请求作者 作者工作PR变更建议(通常为1) QA相关人员 负责合并的人员(通常为2或3人)

使用“受让人”便于将来定位PR。我的一个项目有>3000 pr。

作者:raya-dumas

是:关闭是:pr受让人:raya-dumas

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

和其他类似的查询，以简化搜索过程。“里程碑”对于简化PR搜索也很有帮助。

根据接受的答案。是的，“受让人”的定义比较宽松，可以根据不同团队的需要进行不同的使用。

在我们由8名开发者组成的团队中，大多数PR都有1名审查员，他负责提出修改建议并最终批准PR。在审查员阶段，“受让人”是打开PR的人;之后，如果PR被其他开发者接手，就会增加一个新的“受让人”。一旦PR被批准并准备好进行QA或直接合并，就会添加一个新的QA“受让人”。这样“受让人”列表就会增加。

我们用“受让人”来统称下列人员:

拉请求作者 作者工作PR变更建议(通常为1) QA相关人员 负责合并的人员(通常为2或3人)

使用“受让人”便于将来定位PR。我的一个项目有>3000 pr。

作者:raya-dumas

是:关闭是:pr受让人:raya-dumas

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

和其他类似的查询，以简化搜索过程。“里程碑”对于简化PR搜索也很有帮助。

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

当你添加一个审阅者时，它实际做的是创建一个“审阅请求”:

审阅者会得到通知(就像“受让人”一样)，但现在他们实际上有一项任务可以完成，即对拉请求提供“审阅”:

在审稿人离开审稿(批准或要求更改)后，该信息将在GitHub API和接口中跟踪:

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

编辑:

在与几个OSS维护者讨论后，评审员被定义为:评审(某人的代码)，而“受让人”的定义在下面解释。

对于“审稿人”:您希望审查代码的人。不一定是负责该领域或合并提交的人。就像GitHub自动提示的那样，可能是以前处理过这段代码的人。

对于“受让人”:由项目团队/维护者决定，没有严格的定义。它可以是PR的开启者，也可以是负责该领域的人(他将在审查完成后接受PR，或者只是关闭它)。GitHub并不能定义它为项目维护者开放什么，什么最适合他们的项目。

之前的回答:

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

对于具有写访问权限的用户的PR:受让人将是打开PR的同一人，评审员将取代旧的受让人函数(审查代码)，成为受让人选择的人。

对于没有写权限的用户(外部贡献者)的PR:具有写权限的人将分配自己(或其他有写特权的成员)来审查PR(审稿人)。受让人为空白。

对于来自外部贡献者的未完成PR:写访问成员将接受未完成的工作并为她分配。作为受让人，她将负责完成任务。因为pr的主要目的是审核变更，所以她会选择其他一些人来审核变更。

在GitHub中，评审员是审查拉请求的人。项目所有者可以向任何维护者请求审查，他们甚至可以设置一个选项，这样只有当其中一个具有写权限的维护者审查时，才可以合并pull请求。

根据github官方文档，受让人是负责特定问题和拉请求的人。作为一名审稿人，它有时会感到困惑。它实际上是用来解决问题的，而不是拉请求，这样当我们收到一个问题时，我们就可以分配一个人来解决它。在拉取请求中，受让人指的是在收到其他维护者的评论和更改请求后，负责合并该拉取请求的人。

之前，GitHub只有一个受让人字段，没有审稿人字段。当时没有区别，所以assignee字段最常被用作审阅者字段。

但是要以适合你项目的方式使用它们。