3

是否有一种工具可以在 git 中使拉取请求和组合评论变得万无一失且安全？

我知道有几个相关的问题，已经在 github 上提出过（另请参阅：使用 git 进行代码审查，在线代码审查工具与 Git 集成）。

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

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

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

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

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

我对此解决方案的建议：

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

不幸的是，我不知道 gerrit 并且文档很少。是否可以在 gerrit 中实现此工作流程？是否有另一种工具可以满足这些要求？

4

3 回答 3

1

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

需要记住的一件事 - 发出拉取请求时，补丁可能能够干净地合并，但以后仍可能存在合并冲突。如果开发者 A 发出 pull request 1，可以干净合并，那么开发者 B 发出 pull request 2-9，也可以干净合并，如果 2-9 先审核并提交，则 pull request 1 可能不再干净合并。

Gerrit 有能力尝试检测这一点，并在需要重新定位补丁时提醒用户。

于 2012-07-11T15:38:52.680 回答
1

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

可以将 Gerrit 限制为仅应用快进的补丁，拒绝那些需要合并的补丁。如果你的项目不止几个人，这可能会减慢你的速度：提交的人越多，补丁在被接受之前就越有可能需要重新定位。

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

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

于 2012-07-20T16:57:59.980 回答
0

我真诚地推荐Critic，一个在 Opera Software 开发和使用的 Git 评论系统。W3C 也使用它来审查测试。

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.

Critic 确实有自己的存储库。它带有一些钩子来做不同的事情，但是对于您的用例，您可能会自己编写一些。

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

这个可以。或者实际上，您（作为审阅者）为要审阅的内容设置了审阅过滤器。还有“观看”过滤器。在小型仓库中，我只是对 / （所有内容）进行过滤。在更大的项目中，我有/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).

好多了，两者都可以。我们使用它的方式是变基。你可以自己做，它会找出你改变了什么。如果您更改内容并进行 rebase，它会对您很生气，但会显示在 3-way review 中发生的所有更改。

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

我们有自己的提交队列，Critic 使用一个简单的扩展连接到该提交队列。这使您可以在接受审核后一键将更改排队。它不会让你推动不干净的树枝。在合并之前执行实际编译和测试运行的是提交队列本身；但您可以允许它合并或重新调整您的更改。遗憾的是，我们的提交队列非常具体，不像 Critic 那样开源。虽然审查系统肯定是最难的部分。

因此，对于critic，您需要在外面编写一些小脚本才能执行“推送回购”。但是对于一些更简单的项目，很容易编写一个小的扩展，当按下“集成”按钮时，它只是将接受的代码合并到主控。

于 2014-09-20T10:05:49.320 回答