【问题标题】:Mandatory reviews (ReviewBoard) before push to remote git repository推送到远程 git 存储库之前的强制审查(ReviewBoard)
【发布时间】:2012-07-01 06:40:18
【问题描述】:

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

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

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

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

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

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

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

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

【问题讨论】:

  • 我刚刚想到的另一个选项是强制(通过 pre-receive 钩子)开发人员只推送新分支,这些分支必须与评论票相关联(分支可以有一个特定的名称,或者可能再次使用 git config )。一旦审核票被接受,一个 cron 作业可能会将其合并到 master 中?

标签: git push review-board


【解决方案1】:

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

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

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

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2018-06-24
    • 2010-10-25
    • 1970-01-01
    • 1970-01-01
    • 2012-05-19
    • 1970-01-01
    相关资源
    最近更新 更多