基于GitHub的代码审查的工作stream程
我正在考虑使用GitHub作为我们的代码审查的主要工具。 像在线评论和比较视图这样的function，似乎有许多像Gerrit这样的工具提供的function。
有其他人使用过GitHub吗？ 如果是这样，你的工作stream程是什么？ 你有什么经验这样做，正面和负面？
当我对此有所了解，并理清什么最适合我们时，我将编辑我的问题，分享我自己的build议工作stream程。
编辑build议的工作stream程
步骤0.使用awesome reviewth.is 设置一个post-receive hook 。
然后：
-
像平常一样
commit -a -s，但在提交消息中追加#reviewthis @username。 -
如果构build失败，则审阅将被跳过，直到构build被恢复。
-
审阅者对逐行或在文件级别进行提交的评论。
-
GitHub会自动通知评论的评论者。
-
审阅者通过电子邮件通知审阅者，当评论与审阅摘要一起完成时。
-
Reviewee回复GitHub中的评论者评论，允许项目访问代码评论的历史logging。
我最大的问题是步骤2和步骤4/5。 Gerrit很好地工作，除非构build成功，否则不要求评论; 我想在GitHub中做到这一点。 步骤4/5也有可能让人讨厌（多封电子邮件），并减less审查过程的自动性（需要通过电子邮件发送摘要）。
如果有帮助，我们使用Hudson作为我们的构build服务器。
对这些问题的任何想法也会有所帮助。
我已经使用它了。 我使用的工作stream是在主题分支上完成工作，并在该分支上发送拉取请求。 审查人员使用在线评论（和提交）来检查代码和提交。 编码人员采取这种反馈，并对该主题分支进行破坏性重新分配，重新推送（重写他的github回购中的历史logging），然后重复审查周期，直到合并为止。
编辑：在他的博客上的Githubber描述了他们用来开发github本身的方法，这和我提出的非常相似。 链接
更新：我现在已经在我的开源项目中使用这个工作stream程，在我的专业工作中它仍然很好。
在我的工作中，我们几乎按照“使用pull请求”中描述的过程来进行代码审查，我们对此非常满意。
