如何根据症状避免作为集成商的重复代码错误？

Question

When integrating submodule-releases into parent projects I regularly encounter bugs which are only visible and triggered when integrated. This is normal. Bugs are normal. We debug them, fix them and submit them into the submodule.

Now it happened several times that such fixes are overwritten by a submodule-developer later on and reoccur in the project which integrated this submodule.

Over time and due to virtually no intelligent tracking of their behavior and their symptoms it happens that it was forgotten and it is fixed again. This is extremely time-consuming especially if it is tricky one.

Hence my question: how can I technically store the 'behavior' of a bug to be "reminded" when I see its symptoms again?

Is there a tool which addresses my problem. Anything I can used to categorize fixed bugs by symptoms?

One idea I had was to extend a static-analyser (such as coverity or clang-analyzer) with custom-patterns. This would not address the behavior/symptoms-approach but I could analyze the code during compilation with patterns created during the first fixing: "if this code is written in a certain way it is not good". In my experience I could address quite an amount of bugs this way, but not all of them.

I added C and C++ tags as these are the languages I'm using.

UPDATE : As there were questions in the comments: We are using git. and the bugs which are re-appearing are committed months or even years after their first correction.

UPDATE : we are using Mantis for bug-tracking.

Answer 1

This is not a tool, but rather a process. I have used BFV (Bug Fix Verification) tests to do this. Everytime you fix a bug, you add an automated BFV test for it. The name of the test would be BFV#bugno - this is the bug number in the bug database. As part of all builds which are given to testing, run all BFV tests as part of regression testing. If BFV2042 fails, you can look up Bug#2042 in your bug database to be reminded about it. If you are running regression tests before accepting merges from submodule branches, then it's even better.