在将子模块发布集成到父项目中时，我经常遇到只有在集成时才可见和触发的错误。这个是正常的。错误是正常的。我们调试它们，修复它们并将它们提交到子模块中。
现在发生了好几次这样的修复被子模块开发人员覆盖，并在集成该子模块的项目中再次出现。
随着时间的推移，由于几乎没有智能跟踪他们的行为和他们的症状，它会被遗忘并再次修复。这是非常耗时的，尤其是在棘手的情况下。
因此我的问题是:当我再次看到它的症状时，我如何从技术上存储错误的“行为”以便“提醒”？
是否有解决我的问题的工具。我可以用来按症状对修复的错误进行分类吗？
我的一个想法是使用自定义模式扩展静态分析器(例如 coverity 或 clang-analyzer)。这不会解决行为/症状方法，但我可以在编译期间使用第一次修复期间创建的模式分析代码:“如果这段代码是以某种方式编写的，那就不好了”。根据我的经验，我可以通过这种方式解决相当多的错误，但不是所有错误。
我添加了 C 和 C++ 标签，因为这些是我正在使用的语言。
更新:由于评论中有问题:我们正在使用 git。并且重新出现的错误是在第一次更正后数月甚至数年出现的。
更新:我们正在使用 Mantis 进行错误跟踪。
最佳答案
这不是一个工具，而是一个过程。我已经使用 BFV(错误修复验证)测试来执行此操作。每次修复错误时，都会为其添加一个自动 BFV 测试。测试的名称将是 BFV#bugno - 这是错误数据库中的错误编号。作为所有用于测试的构建的一部分，运行所有 BFV 测试作为回归测试的一部分。如果 BFV2042 失败，您可以在您的错误数据库中查找 Bug#2042 以获得有关它的提醒。如果您在接受来自子模块分支的合并之前运行回归测试，那就更好了。
关于c++ - 作为集成商，如何根据症状避免重复出现的代码错误？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13051150/