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