在推送到远程git存储库之前的强制性评论(ReviewBoard)

时间:2012-06-29 18:02:04

标签: git push review-board

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

不幸的是,git pre-push hooks不是一个选项,并且永远不会成为我所看到的。我看到的唯一选择是使用预接收挂钩,但是将它们与评论联系起来有点棘手。

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

  • 代码,提交,代码,提交......
  • 审核后(生成新评论)
  • 修复问题,提交,审核后(使用新差异更新审核单)
  • 一旦审核被接受(状态:发货!),再次使用“#review”这样的关键字提交(这必须是一个提交 - 我想如果不需要更改的话)
  • git push

预接收挂钩必须检查关键字,检查相应的评论是否确实被接受,否则退出并显示错误。

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

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

尽管如此,所有这些解决方案都有点“脏”。有人设法建立这样的环境,或者可以在这里提供任何提示吗?请注意,所有这些都必须在共享主机上工作,我真的希望能够使用我现有的软件集。

1 个答案:

答案 0 :(得分:0)

你可以编写一个post-receive钩子来搜索你的ReviewBoard安装,以确保在完成的审查中存在被推入的内容的HEAD。这会将您的工作流程改为:

  • 代码,提交,代码,提交,代码,提交......
  • 审查后
  • 使用重新设计的代码修复问题,提交,审核后
  • git push

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