运行lint和单元测试脚本的预提交或预推挂钩值得吗？

Question

我想预提交挂钩( lint和正在运行的单元测试)的论点是，每个提交都是干净的。

反对它们的理由是，它们需要很长时间才能运行，如果您经常提交的话，这可能会加起来。

同样的情况也适用于预推钩，除非它们可能发生的频率较低。此外，如果您有连续的集成设置(运行相同的lint和测试脚本)，您基本上必须等待两次，而结果几乎一直都是一样的。

Answer 1

是的，也不是。

是您要在脚本中进行的操作，值得吗？

在工作中，我们在windows环境中遇到了git问题。文件系统不区分大小写，并带来各种乐趣。我们使用预提交钩子来确保所有的分支名称都是小写的。这是一次快速检查，省去了很多麻烦。

我们的post提交钩子检查以查看所针对的分支是否类似/stream/xyz。如果是的话，它也会将提交消息发送到流松弛通道，以通知那些与代码管理没有很大关系的团队成员，但是他们可能想知道已经完成的工作(经理)，或者在下一个构建中可能会进行一些测试。

这是你的过程吗？

如果这是每个开发人员的期望，那么拥有较长的提交时间就不是问题。他们成功地运行了x，y和z。

类似地，您可以通过检查结果来强制执行此操作。如果结果是干净的，日期在你的项目中的所有文件之后，那么很明显，它们是运行的，并且是好的。

再一次，这可能是浪费时间和资源。也许一个专用的CI盒更好。

但是，所有这些都是挥手而不是你想要实现的过程。只有这样，您才能确定这些脚本钩子是否合适。

Answer 2

这在很大程度上取决于您的团队分支/合并和工作模型、linter规则的质量、单元测试的质量以及两者的实际运行时间。

当开发人员主要提交到他们的本地分支，或者提交或推送到一个独立的特性分支时，不干净提交对其他团队成员的影响很低，所以他们通常是可以容忍的。但是假设一个变更集直接合并到一个公共的dev分支中，或者合并到一个共享的特性分支中，然后下一个dev将不干净的更改提取到他/她的本地工作副本中。例如，当他/她注意到失败的单元测试时，这将使流程变得非常无效，因为可能不清楚根本原因是他/她自己的本地更改还是前一个合并。

如果这是您在团队中所经历的，那么预推送钩子可能是一个有用的解决方案。但是，如果这些验证的运行时间造成了麻烦，那么您应该尝试优化。也许你可以把自动测试分成一个“慢”部分，这个部分通常只在CI服务器上运行，而一个运行起来像“好”单元测试的快速部分应该运行得非常快。这可能有助于简化这一进程。