在git中，有没有一个工具可以让pull请求和组合评论变得简单可靠？
我知道Github已经提出了一些相关的问题（另请参见：Using git for Code Reviews，Online Code Review Tool with Git Integration）。
人们一直建议使用gerrit或gist。
在前面的问题中提出的解决方案有很好的接口，但是在访问控制方面却失败得可怕。我们的公司太小了，不可能强迫一个人检查代码，也不可能有专门的维护人员。因此，我们正在寻找一种工具，以确保（或至少鼓励）在将代码推送到中央存储库之前对其进行检查。
注意：绝对用户访问控制是不必要的，因为我们通常信任我们的员工。但是，我们希望禁止直接推送到我们的中央存储库，而不限制推送到单个人员的权限。
因此，工具（或工具和脚本的组合）应至少完成以下任务：
使拉取请求在Web界面中可见。（格瑞特做到了）
中央存储库链接到该工具，因此可以进行只读访问，但推送操作至少需要另一个人查看和确认变更集。
负责评审和确认的人员可以是开发团队中的任意人员。
该工具必须自动检测（并拒绝）导致合并冲突的拉取请求。
它不应该使用已知的git函数来更改提交的sha1散列。
我对此解决方案的建议是：
使用gerrit处理请求和审查处理。
格瑞特应该总是有一个主人的复制品。
对于每个pull请求，gerrit都会检查补丁是否适用于master而不发生冲突（这将是一个脚本钩子，我不知道gerrit是否提供了这些补丁）。
中央存储库归具有shell访问权限的特权用户所有（此处命名为gerrit），并通过http（s）公开。
每当其他人审查代码时，web界面上会有一个apply按钮，它会自动将更改推送到中央存储库。
不幸的是，我不知道格瑞特和文件是稀缺的。是否可以在gerrit中实现此工作流？是否还有其他工具可以满足这些要求？
最佳答案
严格地说，您不需要让gerrit将更改推送到另一个存储库进行托管（尽管它有允许推送的内置钩子），因为gerrit可以充当存储库主机。
可以限制gerrit只应用快速前进的补丁，拒绝那些需要合并的补丁。如果你不止有几个人在做这个项目，这可能会让你慢下来：投入的人越多，在被接受之前就越有可能需要重新调整补丁。
应用补丁并不是一个简单的点击操作：在审阅了补丁之后，审阅者必须首先选择一个分数（范围从-2到+2），并用+2启用“立即应用”按钮。如果没有CI系统验证修补程序，则它们可能还需要指示已验证源代码是否有效。如果您确实有一个ci bot，并且在审阅者查看代码时它还没有完成，则他们可以留下反馈，任何人（受权限限制）都可以在ci bot完成时触发合并。
您对任意团队成员的要求是可以满足的，除非您的意思是“不是提交更改的成员的任意团队成员”。我想这是你真正想要的，但你可能会让警方追溯到这一点。