我们正在从Bitbucket迁移到GitHub，而我们正在努力的一件事是对等代码审查，在Bitbucket上的运行非常顺利，如下所示：

1. 作者打开了一个拉取请求（GitHub：相同）
2. 作者将他/她的同事添加为审阅者（GitHub：??在这里与多个受让人苦苦挣扎）
3. 评论者：
   1. 批准带有绿色复选标记的PR （GitHub：??）
   2. 添加了评论（GitHub：相同）
   3. 创建轻量级任务（GitHub：如果- [ ]PR描述中使用了语法，则类似；可耻的是，它不适用于任务）
4. 有一个PR列表，我可以一目了然地看到它们，可以进行审查，可以合并，还需要进一步关注（GitHub：??）

我应该指出，我们要尽可能避免使用第三方代码审查工具，并希望通过某些解决方法保留在原始GitHub上。

据我所知，大多数步骤都是按照惯例在Github上完成的，而不是通过Github提供的任何官方程序完成的。

我的雇主使用Github，我经营许多小型开源项目，并偶尔为其他开源项目做出贡献。

这是我通常看到的结果：

作者添加他/她的同事作为审阅者：

每个项目的情况各不相同，但总的来说，指派的同行评审员都是该项目的所有贡献者。

开源项目似乎有一个粗略的层次结构-也许它们的约定是仅在“核心”贡献者表示同意之后才合并。

在我目前受雇的这家商店中，团队中任何六个开发人员的批准后，我们​​就会合并。

在极少数情况下，团队中的某人可能会使用注释来专门召集另一个开发人员，他们认为应该在合并之前先对代码进行同行审查，但是否则，凡是先到达那里并感觉这样做的人都可以进行审查并提出意见。

审稿人批准：

批准通常通过对拉取请求进行注释（表示“ +1”或“ lgtm”）来表示（对我来说很好）。

轻量级任务：

我也使用了复选框，但是在大多数情况下，对请求请求的每个注释都被视为隐式的“任务”，可以通过以下方式解决：

• 更改该行注释的代码
• 回应另一条评论

一目了然地查看了哪些已获批准，哪些仍需要审查：

我使用了Chrome 的Looks Good To Me扩展程序，该扩展程序从Pull Requests屏幕提供了这样的视图。不过，请求请求列表视图似乎已被最近的Github更改所破坏。