在GitHub博客上宣布的于2016年12月7日添加的功能介绍了将审阅者添加到Pull Request中的选项
现在，您可以明确要求协作者进行审核，从而可以更轻松地指定要审核请求请求的人员。
您还可以在拉取请求页面侧栏中看到正在等待审阅的人员的列表，以及已经离开的人员的审阅状态。
然而，明确设置了PR的审稿已通过指定的人（做受让人选项）。
现在有了这两个选项，由于每个选项都具有相同的最终目标，每个选项的作用是什么？
Answers:
编辑：
在与多个OSS维护人员讨论之后，审阅者的定义是：应审阅（某人的代码），而“受让人”的定义更为松散，下面将进行解释。
对于“审阅者”：您要审阅代码的人。不一定是负责该区域或负责合并提交的人员。可以像GitHub自动建议的那样，是以前处理过那部分代码的人。
对于“受让人”：取决于项目团队/维护者的含义，并且没有严格的定义。它可以是PR的开放者，也可以是负责该领域的人员（在审核完成后或将其关闭后将接受PR）。并不是由GitHub来定义它是什么，让项目维护者可以选择最适合其项目的工具。
先前的答案：
好吧，我继续回答我自己的问题。
对于具有写访问权的用户的PR：受理人将是打开PR的同一人，审阅者将替换旧的受理人功能（审阅代码），这是该受让人选择的人。
对于没有写访问权限的用户的PR（外部贡献者）：具有写访问权限的人员将指派自己（或其他写特权成员）来审核PR（审阅者）。受让人是空白。
对于来自外部贡献者的未完成的PR：写访问成员将承担未完成的工作并分配给她。她将作为受让人负责完成任务。由于PR的主要原因是审查变更，因此她会选择其他人来审查变更。
在GitHub中，审阅者是审阅拉取请求的人。项目所有者可以从任何维护者那里请求审阅，他们甚至可以设置一个选项，以便仅当其中一个拥有维护权限的维护者对请求进行审阅时，才能合并拉取请求。
根据github的官方文档，受让人是一个致力于特定问题和请求请求的人。有时将它作为审阅者会感到困惑。实际上，它应与问题一起使用，而不是与拉取请求一起使用，以便当我们收到问题时，可以指派人来解决它。在请求请求中，受让人是指在收到其他维护者的评论和更改请求后负责合并请求请求的人。
根据公认的答案。是的，“受让人”的定义较为宽松，可以根据团队需要进行不同的使用。
在由8个开发人员组成的团队中，在大多数PR中，我们只有1位审阅者，他们提出更改建议并最终批准PR。在审核阶段，“代理人”是指打开PR的人；稍后，如果PR被其他开发人员接受，则会添加新的“代理人”。一旦批准PR，并准备进行质量检查或直接合并，便会添加新的质量检查“受理人”。这样，“受让人”列表就会增加。
我们使用“受理人”来共同指定以下人员：
使用“代理人”有助于将来轻松定位PR。我的一个项目拥有> 3000个PR。
is:open is:pr author:raya-dumas
is:closed is:pr assignee:raya-dumas
或者只是author:raya-dumas查找作者创建的所有项目（问题，PR）
和其他类似的查询，以简化搜索过程。“里程碑”对于简化PR搜索也非常有用。
在GitHub之前，只有一个受理人字段，而没有审阅者字段。当时没有区别，因此受让人字段最常用作审阅者字段。
但是，以适合您项目的任何方式使用它们。