你可以让你的hooks文件夹成为另一个Git存储库，并将其链接为子模块…

我想，只有当你有很多成员和钩子定期改变时，这是值得的。

您可以使用托管解决方案来进行预提交钩子管理，例如预提交。 或者为服务器端git-hook提供集中式解决方案，如date .io。 它有内置的策略，如:

检测和防止秘密的合并。 执行正确的Git用户配置。 强制Jira票集成-在拉请求名称/提交消息中提到票号。

它不会替换所有的钩子，但它可以帮助开发人员使用最明显的钩子，而不必在每个钩子上都安装钩子 开发人员的电脑/回购。

免责声明:我是Datrees创始人之一

在Git 2.9中， 配置选项核心。hooksPath指定自定义钩子目录。

将钩子移动到存储库中的钩子跟踪目录。然后，配置存储库的每个实例来使用跟踪的钩子，而不是$GIT_DIR/hooks:

git config core.hooksPath hooks

通常，路径可以是绝对的，或者相对于钩子运行的目录(通常是工作树的根;参见man githooks的描述部分)。

我想把几个答案合并成一个。假设你在你的项目/目录下:

设置自定义钩子

创建.githooks目录，并将你的钩子放在其中。(参见.git/hooks的例子) 创建一个.gitconfig文件，指向目录¹: Git config -f .gitconfig core。hooksPath .githooks 在你的Makefile中创建以下规则 enable-git-hooks: Git配置—本地包含。路径. . / .gitconfig $(警告记住，你必须审查自定义钩子!)

启用自定义钩子

每个开发人员都应该在检查后显式地启用这些自定义钩子。在README中添加一个指令，就像这样:

通过make Enable -git-hooks检查自定义钩子后启用它们。

你可以让你的hooks文件夹成为另一个Git存储库，并将其链接为子模块…

我想，只有当你有很多成员和钩子定期改变时，这是值得的。

要对hooks目录进行版本化(假设它存储在hooks/中)，在工作副本根目录下创建一个.gitconfig文件，包含以下内容:

[core]
hooksPath = hooks

它将覆盖.git/config。