我想编写一个预提交挂钩，告诉您是否改进/恶化了项目的某些代码指标（即平均函数长度）。钩子必须知道以前的平均函数长度是多少，而我不知道在哪里存储该信息。一种选择是在 repo 中存储一个额外的 .metrics 文件，但这听起来很笨拙。另一种选择是git stash，计算指标git stash pop，再次计算指标并打印增量。我倾向于选择后者。还有其他解决方案吗？
【问题讨论】：
标签： code-metrics pre-commit-hook
免责声明：我是Metrix++ 工具的作者，我在下面描述的工作流程中使用了该工具。我想同样的工作流程可以用其他能够比较结果的工具来执行。
如果您添加几个 CI 检查（请参阅以下步骤），您建议的其中一个想法非常有效。我觉得很结实。不知道你为什么认为它很笨重。
我有一个包含指标结果的文件，该文件在每次提交之前都会更新并存储在 VCS 中。让我们将此文件命名为 metrics.db，并考虑在项目的构建/测试中自动化以下工作流程：
1) 如果 metrics.db 自上次检出后未更改（即它是上一个/基本修订的原始数据），请将其复制到 metrics-prev.db
2) 收集当前代码的指标，再次生成 metrics.db 文件。 注意：当指标工具可以进行迭代扫描以获得最佳性能（即为更新的函数/类计算指标）时非常有用，因此它使您有机会在每次构建时运行指标工具，包括迭代。
3) 比较 metrics-prev.db 和 metrics.db。如果指标识别出回归，则构建失败并且 [可选地] 不允许提交 - 团队规则。如果指标良好，则构建成功，并且可能会发生提交。
4) [可选] 您可以运行持续集成 (CI)，它验证实际提交的 metrics.db 文件是否对应于相同修订版本的提交代码（即执行相同的 1-3 步并确保差异在步骤 3) 处为零。如果 diff 不为零，则意味着有人忘记更新 metrics.db 文件，并且可能没有执行 pre-commit 检查，所以恢复更改。
5) [可选] 如果您从上一个版本中获取 metrics.db 作为 metrics-prev.db，CI 可能会执行步骤 1-3。在这种情况下，CI 还可以检查收集的 metrics.db 是否与已提交的相同（步骤 4 的替代或添加）。
我看到的另一个实现：metrics.db 文件存储在一个单独的驱动器中，在 VCS 之外，自定义脚本能够找到相应的 metrics.db 以进行修订。我发现这个解决方案不可靠，因为驱动器可能会消失，文件可以移动和重命名，等等。因此，将文件放在 VCS 中是更好的解决方案，但任何方法都可以。
我已尝试执行您建议的替代方案：切换到上一个版本并运行度量工具两次。我放弃了这种方法有几个原因：指标检查脚本会更改您的源文件（因此，不可能将其包含到迭代重建中并继续与您的 IDE 顺利工作，因为它会抱怨更改的文件），其次它非常慢性能（与迭代重新扫描相比，它非常慢）。
希望对你有帮助。
【讨论】：