Git hooks - 从远程存储库传播？
我目前正在寻求将现有的 SVN 存储库转换为 git，然后在允许推送之前使用 Reviewboard 进行审核。我最近才开始使用 git，而且远不是这方面的专家，但是我想做的是有一个预推送钩子，它运行“后审查”以将更改提交到 ReviewBoard。我有一个钩子可以执行此操作，但是看起来这不会自动传播到存储库的克隆。阅读周围的内容听起来这并不是为了防止向用户强制执行可执行代码，但是这是一个仅供内部使用的存储库，我们希望强制执行此策略和其他一些策略。有没有办法强制 git 将钩子传播到远程克隆，或者我们是否需要指示我们的开发人员运行将这些钩子放在本地存储库中的东西？
I'm currently looking to convert an existing SVN repository to git, and then to use Reviewboard for reviews before allowing pushes. I've only recently started using git and am far from an expert on it, however what I would like to do is have a pre-push hook which runs "post-review" to submit the changes to ReviewBoard. I have a hook working that will do this, however it looks like this is not propagated automatically to clones of the repository. Reading around it sounds like this isn't done to prevent forcing executable code on a user, however this is an internal-only repository and we want to enforce this and a few other policies. Is there a way to force git to propagate the hooks to remote clones or do we need to instruct our developers to run something that places those hooks in their local repos?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Git 没有内置支持在克隆之间传输钩子（无论是可选的还是其他方式）。它具有默认模板，您可以修改或添加到新存储库，但这些模板是从本地文件系统（或网络文件系统，视情况而定）中提取的。您可以使用一个系统来复制它们，或者将钩子本身放入存储库中并要求开发人员正确配置其克隆。
当推送发生但在更新引用之前，也可以在中央裸存储库上运行您想要的挂钩。这可以通过预接收或更新挂钩来完成。这是否可以接受取决于该挂钩的实际功能，您的帖子中尚不清楚这一点。
阅读http://www.reviewboard.org/docs/manual/dev/faq/< /a> 听起来也许您应该鼓励您的开发人员使用主题分支。一旦更改获得批准，它们就可以合并到发布分支中。您可以有一个更新挂钩，它只允许特权用户或任何其他条件推送到特定分支。这也可以使用 Gitolite 来完成，您可以在 http://progit.org/book 上阅读有关 Gitolite 的信息/ch4-8.html
如果您不打算使用 Reviewboard，则可以考虑http: //code.google.com/p/gerrit/ 与 Git 集成得更好，并且明确支持此工作流程
Git has no built-in support for transferring hooks between clones, optional or otherwise. It has default templates that you can modify or add to for new repositories, but those are pulled from the local filesystem (or network filesystem, as the case may be). It's possible that you could instrument a system for copying them, or put the hooks themselves into the repository and ask that developers configure their clone correctly.
It might also be possible to run the hook you want on the central bare repository, when the push happens but before the ref is updated. This could be done with a pre-receive or update hook. Whether this is acceptable depends on the actual functionality of this hook, which isn't clear from your post.
Reading http://www.reviewboard.org/docs/manual/dev/faq/ it sounds like maybe you should encourage your developers to use topic branches. Once changes are approved, they can be merged into release branches. You could have an update hook which only allows pushes to particular branches from privileged users, or any other criteria. This could also be done using Gitolite, which you can read about at http://progit.org/book/ch4-8.html
If you're not committed to Reviewboard, you might consider http://code.google.com/p/gerrit/ which is better integrated with Git and explicitly supports this workflow