我们的存储库具有自定义状态检查，这些检查根据我们更改的文件数而被触发。如果单个PR中更改的文件数量很大，则这些状态检查可以降低下游依赖性。 （在这些状态检查中有对服务的请求）。我不是在这里讨论这些状态检查以及为什么它们首先存在的问题，目前我们无法更改状态或扩展服务以处理此类负载。
进行这些大更改的想法是在pre-commit上添加一个git钩子，该钩子基本上得到当前分支和远程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不会过时，否则钩子不会失败，但是如果本地主服务器过时，则拉取请求的差异仍然很大。
是的，这里的隐患是该服务在开发人员机器上运行，这意味着CI系统的完整性取决于开发人员安装pre-commit钩子的意愿和能力，而不是覆盖它。正如在此之前和其他地方所提到的那样，不可能依靠pre-commit钩子来执行策略，因为开发人员计算机不受信任。
您最好将其放入CI脚本中，如果更改数量很大，则尽早失败。即使这些策略决策是放弃而不是运行其余CI任务，您的CI系统也是做出决策的正确位置。或者，如果您的Git服务器支持pre-receive挂钩，则可以在那里进行工作。
此外，像这样的pre-commit钩子使高级用户难以创建一系列逻辑提交，甚至难以创建修订提交以压入较旧的提交。作为一个这样的用户，如果每次想添加一些提交时都不得不等待提取操作，我会很不高兴，并且我希望您的用户会删除该挂钩或强制使用--no-verify。话虽如此，它不会破坏pre-commit挂钩中的任何内容，尽管您会发现这样做会破坏用户对git push --force-with-lease的使用以及潜在的混乱的编辑器集成。