这个基于评论的Git工作流程可以由Gerrit强制执行吗？

Question

是否有一个工具，可以使git中的pull-requests和组合评论变得简单且安全？

我知道有几个相关的问题已经在github上提出过了（另请参阅：Using git for Code Reviews，Online Code Review Tool with Git Integration）。

人们一直在建议使用gerrit或gist。

以前的问题中提出的解决方案具有良好的界面，但是在访问控制方面它们可能会失败。我们公司太小，不能强迫一个人审查代码或有专门的维护人员。因此，我们正在寻找一种工具来确保（或至少鼓励）代码在被推送到我们的中央存储库之前进行审核。

注意：绝对用户访问控制不是必需的，因为我们通常信任我们的员工。但是，我们希望禁止直接推送到我们的中央存储库，而不会限制推送给单个人的权限。

因此，工具（或工具和脚本的组合）至少应该完成以下任务：

• 在网络界面中显示拉取请求。 （格里特实现了这一点）
• 中央存储库链接到该工具，以便可以进行只读访问，但是推送需要至少另一个人查看和确认变更集。
• 负责审核和确认的人可以是开发团队中的任意人员。
• 该工具必须自动检测（并拒绝）拉取导致合并冲突的请求。
• 它不应该使用已知会改变提交的SHA1哈希的git函数。

我对此解决方案的建议：

• 使用gerrit进行拉取请求和审核处理。
• gerrit应该总是有一个主人的克隆。
• 对于每个pull请求，gerrit会检查补丁是否适用于master而不会发生冲突（这将是一个脚本钩子，我不知道gerrit是否具有这些功能）。
• 中央存储库由具有shell访问权限的特权用户（此处名为gerrit）拥有，并通过http（s）公开。
• 每当其他人审核代码时，网络界面中都会有一个应用按钮，会自动将更改推送到中央存储库。

不幸的是，我不知道gerrit和文档是稀缺的。是否可以在gerrit中实现此工作流程？还有其他工具可以满足这些要求吗？

Answer 1

我认为Gerrit将满足您的大部分/全部需求。您可以集成一个CI工具，例如Jenkins，它可以与Gerrit交互并在需要时添加其他功能。

要记住的一件事 - 补丁可能能够在发出拉取请求时干净地合并，但以后可能仍会发生合并冲突。如果开发人员A生成拉取请求1，它可以干净地合并，那么开发人员B发出拉取请求2-9，这也可以全部合并，拉取请求1可能不会干净地合并，如果2-9被审查并首先提交。

Gerrit有能力尝试检测此问题，并在需要修补补丁时提醒用户。

Answer 2

严格来说，您不需要将gerrit推送更改到另一个存储库进行托管（尽管它具有允许推送的内置挂钩），因为Gerrit可以充当存储库主机。

可以限制Gerrit仅应用快进的补丁，拒绝那些需要合并的补丁。如果你不仅仅有几个人参与这个项目，那么这可能会让你失望：人们投入的次数越多，补丁在被接受之前就越有可能被重新定位。

应用补丁并不是一次单击操作：审阅补丁后，审阅者必须先选择一个得分（范围从-2到+2），然后选择+2启用“立即应用”按钮。如果您没有CI系统验证补丁，他们可能还需要表明他们已验证源工作。如果您做有CI机器人，并且在审核人员查看代码时尚未完成，他们可以留下他们的反馈，任何人（受权限限制）都可以在CI机器人时触发合并结束。

您对任意团队成员的要求是可以满足的，除非您的意思是“不是提交更改的成员的任意团队成员”。我怀疑这是你真正想要的，但你可能会追溯到这一点。

Answer 3

我真诚地推荐Critic，这是在Opera Software开发和使用的Git评论系统。 W3C也将它用于reviewing tests。

---

make pull requests visible in a web interface. (gerrit achieves that)

评论家这样做。它与Git完全集成。你只需将评论家设置为Git-remote，然后推送到r/your-branch，它将创建一个评论，通过电子邮件将所有匹配的评论者发送给这些文件。

the central repository is linked to that tool, such that read-only access is possible, but pushing requires at least another person to review and acknowledge the changeset.

批评者确实有自己的存储库。它附带了几个钩子来做不同的事情，但对于你的用例，你可能会自己写一些。

the person responsible for review and acknowledgement can be an arbitrary person from the development team.

这可以。或者实际上，您（作为评论者）为您要查看的内容设置了评论过滤器。还有＆＃39;观看＆＃39;过滤器。在小型回购中我只是对/（一切）进行过滤。在更大的项目中我有例如/desktop/linux/例如一个.*.py。

the tool must autonomously detect (and refuse) pull requests that lead to merge conflicts. it shouldn't use git functions that are known to alter the SHA1 hash of the commit(s).

它好得多，它可以做到这两点。我们使用它的方式是使用变基。你可以自己做，它会弄清楚你改变了什么。如果你改变了东西并做了一些改变，它会对你很生气，但会显示三方评论中发生的所有变化。

我们有一个大多数用户已安装的扩展程序，FiddleAndTweak，它允许您直接在Review界面中执行简单的修复，以及在推送之前进行Interactive Rebase。

我们有自己的提交，使用简单的扩展连接到Critic。这样，您可以在接受审核后通过一次单击对更改进行排队。它不会让你推动不干净的分支机构。它是commitqueue本身，在合并之前进行实际编译和测试;但您可以允许它合并或改变您的更改。可悲的是，我们的承诺是非常具体的，而不是像批评家一样开源。虽然审查制度肯定是更难的部分。

因此，对于评论家来说，你需要在外面写一些小脚本才能进行回复＆＃34;推送回购＆＃34;。但是对于一些更简单的项目来说，编写一个小扩展名很容易，只需将接受的代码合并到“＃”整合＆＃39;按钮被按下。