这个问题比技术问题更具流程性。
状况
我使用SonarQube来分析我的代码质量和Git以对我的代码进行版本化。
我的＆＃34;开发＆＃34;分支是构建和SonarQube每晚分析（就某些事情而言）。
在开发分支上我使用＆＃34; SNAPSHOT＆＃34;版本（例如1.1.0-SNAPSHOT）
当一个版本准备好生产时，我创建一个版本分支，将版本分支上的版本设置为固定版本（例如1.1.0）并将开发分支上的版本增加到下一个＆＃34; SNAPSHOT＆＃ 34;版本（前面的例子现在是1.2.0-SNAPSHOT）
至于我的发布分支被允许修改（直到它的最终版本并将合并为主）我还希望了解该分支的质量。
每次我修改发布分支时，版本也会得到一个自动增量的build-nr（所以最终的版本nr将是例如1.1.0.001）
问题
我目前在SonarQube中有一个项目。当从不同的分支建立时，这会导致我的SonarQube时间线内的间隙和跳跃。
例如：
主要问题不仅是版本跳转，还有不同的问题（例如，在发布分支之后，一系列问题在开发时得到修复）。
问题
所以我的问题是：这个问题的最佳解决方案是什么？
答案 0 :(得分：1)
取决于您的目标 - ＆gt;
您是否只是进行分析以了解问题，或者您是否积极地希望人们处理声纳问题并阻止他们创建问题？
比您应该考虑实施某种工具，它在拉动请求中显示声纳问题并尝试在开发过程中详细说明SonarLint的使用
您是否只想了解历史数据，代码库是如何演变的？
比一个分支足够，我会推荐生产分支
您是否希望看到真正的变化，并希望防止过多的新问题＆＃34;但是全功能分支太多了？
比我建议简单地运行开发，生产和发布分支的分析
在我们公司，几乎总是在功能分支上分析新项目，之后没有人会修复声纳问题，这只会产生很多开销。我们确实有一些项目有很旧的源代码，但即使我们尝试使用功能分支分析来改进代码库。
这实际上是一个特定于项目和目标的主题