这个基于评论的 Git 工作流程能够被 Gerrit 实施吗？

Question

有没有一种工具可以在git中使拉取请求和综合审查变得简单而安全？

我知道在github上已经有了几个相关的问题（参见：使用git进行代码审查，带有Git集成的在线代码审查工具）。

人们建议使用gerrit或gist。

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

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

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

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

我的解决方案：

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

不幸的是，我不了解gerrit，文档很少。在gerrit中是否可能实现这种工作流程？或者还有其他工具可以满足这些要求吗？

- Alexander Oh

---

你的购物清单应该使用Gerrit进行覆盖。安装它并尝试一下，它并不是非常难。 - Benjamin Bannier

我建议在Gerrit中让Jenkins标记构建为“Looks OK”，这样您就可以确保它编译/通过测试/符合您的构建指标。 - Benjamin Bannier

@honk：啊，谢谢！我之前没有考虑过持续集成。 - Alexander Oh

我被外部提示到：http://www.chromium.org/developers/testing/commit-queue - Alexander Oh

Answer 1

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

需要记住的一件事是 - 当发起拉取请求时，补丁可能能够干净地合并，但稍后仍可能存在合并冲突。如果开发人员A发起了拉取请求1，该请求可以干净地合并，然后开发人员B发起了拉取请求2-9，这些请求也都可以干净地合并，如果2-9先被审查和提交，那么拉取请求1可能不再干净地合并。

Gerrit具有检测此类情况并在需要重新基于补丁时提醒用户的功能。

- Brad

---

关于合并冲突，在Gerrit中还有一个有用的设置，可以执行三方合并来解决一些简单的冲突，请参见--use-content-merge。 - Ruslan Kabalin

Answer 2

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

可以限制Gerrit仅应用可快进的补丁，并拒绝需要合并的补丁。但是，如果有多个人在项目上工作，这可能会减慢您的速度：提交的人越多，接受补丁之前就必须重建补丁的可能性越大。

应用补丁不是完全一键操作：审核者必须先选择一个得分（范围从-2到+2），其中+2将启用“立即应用”按钮。如果您没有CI系统验证补丁，则还需要指示他们已经验证了源代码的工作方式。如果您有CI机器人但审核人员查看代码时它还没有完成，则他们可以留下反馈意见，任何人（符合权限要求）可以在CI机器人完成后触发合并。

您对于任意团队成员的要求可以满足，除非您的意思是“不是提交更改的成员的任意团队成员”。我认为这实际上是您想要的，但您可能需要以追溯方式管理此事。

- Andrew Aylett

---

我自己得出了与你相同的结论。似乎 Java 实现的 Git 仍然存在一些微妙的错误。因此，我们目前正在研究规避 Gerrit 的托管设施，即使它们在未来可能会有用。此外，使用 Gerrit 进行推送的方式是非常不寻常的，因此我们不确定是否想要将 Gerrit 用于那些对 Git 不太自信的人。 - Alexander Oh

你知道如何使用Gerrit与外部存储库进行交互吗？ - Alexander Oh

Answer 3

我真诚地推荐Critic，这是Opera Software开发和使用的Git审查系统。W3C也用它来审核测试。

---

使拉取请求在Web界面中可见。(Gerrit实现了这一点)

Critic也可以做到。而且它与Git完全集成。您只需将Critic设置为Git-remote，然后推送到r/your-branch，它就会创建一个审查，并向所有匹配的文件的评审人发送电子邮件。

中央存储库与该工具链接，因此可以进行只读访问，但是推送需要至少另一个人审核和确认更改集。

Critic确实有自己的存储库。它带有一些钩子来执行不同的操作，但对于您的用例，您可能需要编写一些自己的钩子。

负责审核和确认的人可以是开发团队中的任何人。

确实可以。或者实际上，您（作为评审人）可以为您想要审核的内容设置审查过滤器。还有“监视”过滤器。在小型存储库中，我只对/（所有内容）进行过滤。在大型项目中，我有例如/desktop/linux/和例如一个带有.*.py的过滤器。

该工具必须自主检测（并拒绝）导致合并冲突的拉取请求。它不应使用已知会更改提交的SHA1哈希值的git函数。

这样做更好，它可以同时完成两个任务。我们使用的方法是使用rebase。您可以自己操作，它会找出您所更改的内容。如果您更改了内容并进行了rebase，它会对您感到非常生气，但会在三方审查中显示所有发生的更改。

我们有一个扩展程序，大多数用户都安装了FiddleAndTweak，它允许您在审查界面中直接进行简单的修复，并在推送之前进行交互式rebase。

我们有自己的提交队列，Critic使用一个简单的扩展连接到它。这使您可以在审核被接受后通过单击将更改排队。它不允许您推送不干净的分支。实际编译和测试运行是由提交队列本身执行的，然后再进行合并；但是您可以允许它合并或rebase您的更改。遗憾的是，我们的提交队列非常特定，而且不像Critic一样开源。尽管审核系统肯定是更难的部分。

所以，对于有critic的情况下，你需要编写一些小脚本来完成“推送到仓库”的操作。但是对于一些简单的项目来说，编写一个小扩展程序只需在点击“集成”按钮时将已接受的代码合并到主分支上非常容易。

- odinho - Velmont