SonarQube怎么做分支分析 SonarQube分支分析结果怎么和主干对比

很多团队把SonarQube接进流水线以后，主干分析通常很快就能跑起来，但一到分支分析，问题就会集中在两处。一处是不确定分支到底怎么建出来，另一处是不知道分支结果和主干该按什么口径去比。按SonarSource当前官方文档，分支分析从Developer Edition起才提供，分支是在分析时传入sonar.branch.name后创建出来的；而分支和主干的对比，本质上又不是靠手工看两份报告，而是靠Reference branch也就是参考分支，配合New Code口径去做差异判断。把这两层先分清，后面配置和看结果都会顺很多。

一、SonarQube怎么做分支分析

SonarQube怎么做分支分析，先不要一上来就在界面里找“新建分支”按钮。官方口径里，分支不是在项目页面手工建出来的，而是在分析阶段由扫描参数或CI自动识别出来的。

1、先确认版本是否支持

官方文档写得很明确，Branch analysis从Developer Edition开始提供。也就是说，如果你现在用的是Community线，主干分析可以做，但多分支分析这条线本身就不是当前版本的标准能力。

2、把分析步骤放进多分支CI

官方对设置步骤的第一条要求，就是把analysis step放进多分支流水线里。换句话说，分支分析不是单独在SonarQube里补跑一遍，而是要让Jenkins、GitLab CI、GitHub Actions这类CI在分支推送时也执行扫描。

3、分析时把分支名带进去

官方文档说明，分支是在传入sonar.branch.name时创建出来的，这个参数表示当前分析对应的分支名。部分CI可以自动识别分支参数，但如果你的流水线没有自动识别，就要手工把这个参数加进去。

4、主干名要和代码仓一致

SonarSource官方还特别提醒过，如果SonarQube里的main branch名称和代码仓里的真实主干名不一致，后续分支历史和对比结果会容易错位。更稳的做法，是先到Project Settings里的Branches and Pull Requests，把主干名改成和仓库一致。

5、分支代码必须真实检出

官方设置文档里还强调了一点，就是被分析的分支必须在CI工作区里被正确checkout。因为后面的分支识别和New Code判断都会依赖当前检出的源码和SCM信息，如果流水线只拉了主干快照，分支分析结果自然不准。

二、SonarQube分支分析结果怎么和主干对比

SonarQube分支分析结果怎么和主干对比，真正关键的不是把两个分支页面并排看，而是先把分支的参考对象定成主干。官方文档对这一点写得很清楚，Reference branch模式下，当前被分析分支会和选定的参考分支做比较，所有差异都会被视为New Code。

1、先把主干设成Reference branch

官方对New Code的说明里明确写到，Reference branch选项可在项目级和分支级使用，适合feature branch场景。你把主干设成参考分支以后，当前分支相对主干的差异就会被识别为新代码。

2、也可以在分析时临时指定主干

除了在界面里配置，官方还提供了sonar.newCode.referenceBranch这个分析参数。文档说明，这个参数会把本次分析的New Code定义临时改成Reference Branch，并按你给出的分支名去比。对某些需要按流水线动态切换对比对象的项目，这条更灵活。

3、对比时重点看New Code，不要只看Overall Code

官方文档已经把结果展示口径说得很清楚，Overview页面和Measures面板都会把New Code和Overall Code分开显示。你如果是想判断某个功能分支相对主干新增了多少问题、覆盖率有没有掉，重点应该看New Code那一层，而不是直接拿全量指标去比。

4、Issues页面可以直接切到新代码问题

SonarSource官方说明，Issues页面有Issues in new code过滤项，可以快速在新代码问题和整体问题之间切换。所以分支和主干做差异审查时，比较实用的做法不是全量翻问题，而是先切到新代码视图，再看当前分支相对主干到底新增了什么。

5、Quality Gate看的是当前分支是否可合并

官方Quality Gate文档写到，质量门状态会出现在主干、其他分支和Pull Request的结果页上，而且条件既可以定义在New Code，也可以定义在Overall Code。对分支场景来说，更有价值的通常是New Code条件，因为它更接近“这次分支改动能不能过门”的判断。

三、SonarQube分支口径怎么定

真正让分支分析长期稳定的，不是参数会不会写，而是主干、参考分支和新代码口径有没有先统一。只要这三层没定住，后面同一个分支今天和主干比、明天又和develop比，结果一定会越来越乱。

1、主干名称一开始就统一

官方已经明确提示，修改main branch会影响后续分析归属，所以项目一开始就要确定SonarQube里的主干到底对应仓库里的main、master还是develop。名称统一之后，分支历史和比较关系才不容易漂。

2、功能分支统一都对比同一条主干

如果团队是标准feature branch流程，就尽量让feature分支统一都拿主干做Reference branch，不要有人拿main比，有人又拿release比。官方把Reference branch定位成New Code的对比基准，这个基准越统一，分支结果越容易横向比较。

3、分支分析和PR分析不要混用

官方把branch analysis和pull request analysis分开建模，前者主要覆盖持续存在的分支，后者则是合并前校验。实际使用时，长期分支用sonar.branch.name，PR流程则走sonar.pullrequest相关参数，两套口径不要混在一起。

4、CI里最好显式传分支参数

官方在维护分支的文档里专门提醒过，如果分析时不显式传sonar.branch.name，结果默认会落到当前项目的main branch上。为了避免改主干或CI识别异常时把分析打错位置，更稳的做法是让流水线明确传递分支名。

总结

SonarQube怎么做分支分析，核心不是在界面里手工建分支，而是把分析步骤放进多分支CI，并在分析时通过sonar.branch.name或CI自动识别把分支创建出来。SonarQube分支分析结果怎么和主干对比，关键也不是手工对两份报告，而是把主干设成Reference branch，再围绕New Code、Issues in new code和分支Quality Gate去看差异。只要把主干名称、参考分支和分析参数这三层先统一，SonarQube的分支分析通常就会顺很多。