Git预提交钩子，用于检查更改的文件数

我们的存储库具有自定义状态检查，这些状态检查将根据我们更改的文件数触发。如果单个PR中更改的文件数量很大，这些状态检查可以降低下游依赖关系。（在这些状态检查中有对服务的请求）。我在这里不是要争论这些状态检查以及它们为什么会出现在那里，在这个时候，我们不能改变这一点，也不能扩展服务来处理这样的负载

阻止这些大的变化的想法是在预提交时添加一个git钩子，它基本上可以获得当前分支和远程主机提示之间不同的文件数量。然后，如果这些文件的数量大于某个特定的数量，我们就要出错

基本上，我要做的就是在git钩子中使用以下命令

# 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安全吗？我需要一些方法来确保本地引用源/头不过时，否则钩子不会失败，但如果本地主控已过时，拉请求仍可能有很大的差异。

是的，这里隐藏的问题是此服务在开发人员机器上运行，这意味着您的CI系统的完整性取决于开发人员安装

pre-commit

钩子而不是覆盖它的意愿和能力。正如前面在这里和其他地方提到的，不可能依靠

pre-commit

钩子来执行策略，因为开发人员机器不受信任

如果更改的数量很大，那么最好将其放在CI脚本中，并尽早失败。您的CI系统是做出策略决策的正确场所，即使这些策略决策是放弃而不是运行其余的CI作业。或者，如果您的Git服务器支持一个

预接收

钩子，那么您可以在那里完成这项工作

此外，像这样的

pre-commit

钩子使得高级用户很难创建一系列逻辑提交，甚至很难创建用于压缩到旧提交中的修复提交。作为这样一个用户，如果每次我想添加一些提交时都要等待获取，我会非常不高兴，我希望您的用户会删除钩子或强制使用

--no verify

---

话虽如此，它不会破坏任何获取

预提交

钩子的功能，尽管您会发现这样做会破坏用户对

git push--force with lease的使用

，还有可能令人困惑的编辑器集成。

旁注：注释以

获取当前分支尖端和

之间的差异开始，然后运行

git diff--缓存

，因此它根本不查看当前分支的顶端，而是查看索引。这适用于预提交钩子，因为将提交的是索引中的内容。只是评论是错误的。