有没有办法强制 Git 下载客户端挂钩作为服务器的预接收操作？

Question

我在一个拥有数千名开发人员的企业环境中工作，我们实现了一些服务器端挂钩来防止推送大文件以及具有某些扩展名和 mime 类型的文件。

问题是，当我们尝试处理我们的用户活动级别时，我们的应用程序基本上爆炸了，所以我认为使用客户端挂钩和边缘计算将是将此处理卸载给用户的最佳方法......但是， 这意味着：

1.- 为了执行规则，我们不能依赖用户为其每个存储库下载和安装挂钩

2.- 我们需要从中心位置使这些挂钩保持最新状态

3.- 所有这一切都应该发生在用户尝试推送之后、解压更改之前

将其绑定到构建脚本或修改存储库将是绝对不行的，因为我不想污染用户的存储库，理想情况下这应该对用户完全透明，这样他们甚至不知道这些规则的处理是在他们这边完成的，并且是防篡改的（即，作为用户，我进入本地钩子目录并修改脚本）。

知道这是否可以通过在服务器上以预接收或类似挂钩启动的一些晦涩的 Git 机制来完成吗？或者也许有一些更好的解决方案，即使方法完全不同？

我厌倦了向用户解释 Git 不是用于存储二进制文件，尤其是发布二进制文件（我们的许多用户都来自于在 SVN、P4 中进行这种可怕的实践）...它会影响我们的 Git 服务器，并开始增加他们的构建时间...然后他们将其归咎于 IT。

您猜对了，我从事 IT 工作，是的...我们尝试过关闭和打开服务器。

Answer 1

简短回答：

\n\n

不。没有内置的 git 功能可以让您从服务器隐形安装客户端挂钩。

\n\n

长答案：

\n\n

是的。虽然没有内置的方法来隐形安装客户端挂钩（也不应该有），但如果您可以控制团队正在使用的机器（例如，能够断言组策略或代表团队运行管理命令）用户）那么就有办法实现您所追求的目标。

\n\n

全面披露：我在 Atlassian 的高级支持团队工作，并且与我们的 Bitbucket 服务器开发人员密切合作。话虽如此，这几乎完全是 git 的问题，而不是 Bitbucket 的问题，所以我将在这里重点讨论这一点。

\n\n

选项 1：覆盖 core.hooksPath

\n\n

（另请参阅： https: //git-scm.com/docs/githooks）

\n\n

默认情况下，git 会在您的存储库中查找$GIT_DIR/hooks/*. 这可以在每个存储库级别和全局级别上进行配置。全局配置非常简单：

\n\n

git config --global core.hooksPath /path/to/custom/hooks\n

\n\n

这将对所有存储库（无论是新的还是现有的）或多或少立即生效。您需要某种方式在每个团队成员的工作站上运行它，但大多数企业环境已经有了远程运行脚本等的方法，因此这实际上只是让您的 IT 管理团队相信这是必要的业务需求的问题。

\n\n

当然，要实际使用自定义挂钩，您需要确保使用普遍可访问的路径（自动安装位置）或 \xe2\x80\x94 可能更安全 \xe2\x80\x94将钩子本地复制到他们的机器上。再次，我希望您有执行此操作的机制，或者可以远程运行脚本以达到相同的效果。

\n\n

如果您想core.hooksPath在本地计算机上尝试该设置，请执行以下操作：

\n\n

$ mkdir ~/.globalgithooks\n$ echo "printf \'hello world\\n\'" > ~/.globalgithooks/pre-commit\n$ chmod +x ~/.globalgithooks/pre-commit\n$ git config --global core.hooksPath ~/.globalgithooks\n

\n\n

然后找到一些存储库（新的或现有的），您可以安全地进行一些虚拟提交，然后您将看到它工作。

\n\n

优点：

\n\n

\n
• 对当前和新创建的存储库均生效
\n

\n\n

缺点：

\n\n

\n
• 删除了在每个存储库的基础上自定义挂钩的能力
\n

\n\n

选项 2：覆盖 git 模板目录

\n\n

（另请参阅： https: //git-scm.com/docs/git-init#_template_directory）

\n\n

当你创建一个存储库时，git 不只是从“无”开始设置它；而是从“无”开始设置它。它使用一个预打包的模板目录，其中包含（引用上面的链接）“一些目录结构，建议的“排除模式”和示例挂钩文件。”您可以将自己的自定义挂钩添加到此模板目录中，并且每当创建新存储库后，它们将被复制到该存储库的本地挂钩集 ( $GIT_DIR/hooks)。有趣的事实：即使您克隆存储库，您仍然创建一个“新”存储库 \xe2\x80\x94 它只是一个新存储库，然后 git 添加上游远程 URL、获取对象并检查默认分支。换句话说，克隆时仍然会使用模板目录，因此将自动为通过克隆创建的任何存储库设置在那里创建的自定义挂钩。

\n\n

同样，您需要对计算机进行某种托管访问才能执行此操作。然而，它可以说比第一个选项更复杂；使用选项 1，您可以简单地将钩子复制到您喜欢的任何位置并运行简单的git config命令，要使此选项起作用，您需要找到该用户的 git 安装的正确模板目录。鉴于 git 可能通过不同的软件包管理器安装在不同的操作系统上，这意味着您需要确定目录所在的位置。默认情况下，在 Linux 中这是/usr/share/git-core/templates；/usr/local/Cellar/git/$GIT_VERSION/share/git-core/templates在我在 macOS 上安装的自制程序中，可以通过 \xe2\x80\xa6 上的符号链接找到它/usr/local/share/git-core/templates，换句话说，你需要拼凑某种逻辑来找到正确的位置并在那里添加你的钩子。即便如此，这也不会影响机器上已有的任何现有存储库。

\n\n

另一种方法是init.templateDir在全局 git 配置中进行设置，从而无需查找现有的临时目录。然而，这迫使您维护所有内容 \xe2\x80\x94 如果将来该结构的某些基本部分发生变化，您将需要维护和更新您的副本。

\n\n

优点：

\n\n

\n
• 在每个存储库的基础上配置挂钩，这意味着您可以根据需要继续使用其他每个存储库的挂钩
\n

\n\n

缺点：

\n\n

\n
• 仅影响新的（初始化和克隆的）存储库；现有的存储库不会知道模板目录中的新添加内容
\n
• 由于需要确定用户的 git 安装位置（或者完全维护您自己的自定义模板目录），配置可能很脆弱
\n

\n\n

对于这两个选项，您需要计算出运行这些选项的频率，以确保您的挂钩保持最新。您可以定期运行这些，或者只要您进行更改，就简单地推送到所有客户端计算机 \xe2\x80\x94 这完全取决于您的管理工具

\n\n

无论你如何解决这个问题，精明的用户总是能够解决它，但我猜这在大多数情况下都不是问题。如果您的开发人员正在积极规避一个告诉他们不要提交某些内容的钩子，以便他们无论如何都可以这样做，那么这就不再是一个技术问题，而是一个管理问题。

\n