Git 预提交挂钩以检查更改的文件数

Question

我们的存储库具有自定义状态检查，根据我们更改的文件数量触发。 如果单个 PR 中更改的文件数量很大，则这些状态检查可以降低下游依赖性。 （在这些状态检查中有对服务的请求）。 我不是在这里争论这些状态检查以及为什么它们首先存在，此时我们无法更改它或扩展服务以处理此类负载。

控制这些大变化的想法是在 pre-commit 上添加一个 git hook，它基本上可以获取当前分支和远程 master 的提示之间不同的文件数量。 然后我们想在这些文件的数量大于某个数量时出错。

基本上我要做的方法是在 git hook 中使用以下命令

# Refresh local reference to origin/HEAD
git fetch

# Get the diff between the tip of current branch and the tip of origin/HEAD and count them
git diff --name-only --cached origin/HEAD | wc -l

... 

这似乎有效，但我有几个问题： 1. 这些方法有什么隐藏的问题吗？ 我想确保我涵盖了所有可以防止打开拉取请求的情况，其中的差异跨越文件数> X。 2. 在 git 钩子中调用 git fetch 是否安全？ 我需要一些方法来确保本地参考源/HEAD 不会过时，否则钩子不会失败，但如果本地主服务器已过时，拉取请求仍然可能具有非常大的差异。

Answer 1

是的，这里隐藏的问题是该服务在开发人员机器上运行，这意味着您的 CI 系统的完整性基于开发人员安装pre-commit挂钩而不是覆盖它的意愿和能力。 正如之前在这里和其他地方提到的，依靠pre-commit钩子来执行策略是不可能的，因为开发人员机器不受信任。

你最好把它放在你的 CI 脚本中，如果更改数量很大，就尽早失败。 您的 CI 系统是制定政策决策的正确场所，即使这些政策决定是放弃而不是运行其余的 CI 作业。 或者，如果您的 Git 服务器支持pre-receive挂钩，您可以在那里完成这项工作。

此外，像这样的pre-commit钩子使高级用户难以创建一系列逻辑提交，甚至创建修复提交以压缩为旧提交。 作为这样的用户，如果每次我想添加一些提交时都必须等待获取，我会非常不高兴，我希望您的用户会删除钩子或强制使用--no-verify 。

话虽如此，它不会破坏pre-commit挂钩中的任何获取内容，尽管您会发现这样做会破坏用户对git push --force-with-lease ，以及可能会混淆编辑器集成。