0

我希望对推送到我们通用远程 git 存储库的任何代码强制使用评论。我选择了 ReviewBoard作为帮助我们实现这一目标的工具,但是在将任何代码推送到存储库之前,我一直在努力使审查成为一项要求。

不幸的是,git pre-push 钩子不是一种选择,也不会成为我所看到的。我看到的唯一选择是使用预接收挂钩,但是将这些与评论联系起来有点棘手。

为了完成这项工作,每个开发人员都必须遵循如下流程:

  • 代码,提交,代码,提交...
  • 审查后(生成新审查)
  • 修复问题、提交、审查后(用新的差异更新审查票)
  • 一旦审核被接受(状态:发货!),再次使用像“#review”这样的关键字提交(那必须是提交——修改我猜如果不需要更改)
  • git 推送

pre-receive 钩子必须检查关键字,检查相应的评论是否确实被接受,否则会出错退出。

我觉得通过在推送操作周围创建一个包装器并拥有一个可以正确处理所有这些的自定义脚本会更好地处理这个问题(它甚至可以在推送之前自动创建一个评论票,使用 git config 分支存储票证 id.. review_ticket 并在一切结束时推送)。这基本上与上面相同,但半自动化,这也意味着它会限制开发人员如何使用分支(虽然不一定是问题)。

最后,我可以让开发人员做他们想做的任何事情,但在远程存储库上运行一个 cron 作业,并检查是否有任何更改未经审查就被推送(有点棘手)并发送警告电子邮件。

不过,所有这些解决方案都感觉有点“肮脏”。有人设法建立这样的环境,或者可以在这里提供任何提示吗?请注意,所有这些都必须在共享主机上运行,​​我真的希望它能够与我拥有的当前软件集一起使用。

4

1 回答 1

0

您可以编写一个接收后挂钩来搜索您的 ReviewBoard 安装,以确保推送的内容的 HEAD 存在于已完成的评论中。这会将您的工作流程更改为:

  • 代码,提交,代码,提交,代码,提交...
  • 后审查
  • 使用重新编写的代码修复问题、提交、后审查
  • git 推送

从而摆脱丑陋的提交修改的事情。

于 2012-07-03T02:42:05.157 回答