SonarQube分支分析怎么开启，还有分支分析出来的结果为什么跟主分支对不上，这些是不少团队在把扫描接入CI之后都会碰到的问题。分支分析这件事，不是说把不同的分支挨个扫一遍再统统塞进同一个项目就行了的，它需要版本那边能支持、扫描时传的参数得对、代码基线要定好，还有对新代码的定义也要一起配合着来才行。另外有一件事得先弄清楚：SonarQube Server的分支分析功能是从Developer Edition才开始提供的，Community Edition一般只保留单个项目的分支视图，所以在动手之前得先确认好版本。

　　一、SonarQube分支分析怎么开启

　　在开启分支分析之前，要先看看当前SonarQube的版本和授权类型是哪一种。如果版本本身就不支持分支分析，就算在扫描参数里硬把分支名加上去，通常也拿不到预期的结果，甚至还会直接报错。版本确认没问题了，再去调整项目那头的扫描脚本和CI流水线。

　　1、确认版本和项目权限

　　项目得先保证自己用的确实是支持分支分析的版本，而且当前登着的账号要有项目分析权限，要不然哪怕分支参数都已经配好了，扫描任务也可能没法把结果正常写进去。遇到多个团队共用一个SonarQube的时候，还得留心项目key有没有被不同的代码仓库或者不同的流水线给混在一起用了。

　　2、配置分支扫描参数

　　在CI脚本或者扫描命令那个位置，把【sonar.branch.name】给加上，让扫描出来的结果能进到对应的分支视图里头。这个参数一般来说都是跟着当前Git分支的名字走的，比如feature、develop、release这些。有几点要注意：主分支的名字不要随便去改，分支名也要跟流水线里的变量保持一致，否则同一个分支很有可能会被当成多条分析记录。

　　3、把分支分析和PR分析区分开

　　分支分析关心的是某一条分支它自己身上的代码质量状况，而PR分析更在乎的是合并之前新冒出来的那些问题。要做PR分析的话，一般得把pull request key、branch和base这些参数都配好，base多数情况下可以指向main分支。这二者的用途不一样，不要拿PR扫出来的结果去作长期分支质量上的判断，也别用分支分析去顶替合并前的检查。

　　二、SonarQube分支分析结果为什么和主分支不一致

　　分支跑出来的结果跟主分支对不上，这其实是一种挺正常的现象，不见得就是扫描搞错了。因为分支上的代码、分析的时间点、质量的配置、对新代码的定义、覆盖率的文件，还有那些排除规则，这几样东西都可能不一样。先要判断一下这个差异到底是代码本身带来的，还是由扫描环境造成的。

　　1、代码内容和扫描时间点不一样

　　分支并不是主分支的复制品，功能分支有可能没赶上主分支后面新合进去的那几笔提交，也可能自己多了一些临时的改动，所以问题数量、重复率、覆盖率、安全热点这些都很可能不一样。如果主分支刚刚合并了一批修复，而分支还没跟着同步上去，那分析结果自然就会有出入。

　　2、新代码的定义没有统一

　　SonarQube里的New Code是可以按照参考分支、天数或者版本这些方式来定的。要是用了参考分支，分析分支就会根据SCM的信息和参考分支当前的状态，去判断哪些算是新代码。假如主分支和功能分支对新代码的划定不一样，质量门禁那边就可能会出现一个能通过、一个被拦下来的情况。

　　3、覆盖率报告和测试报告没对齐

　　分支分析里常碰到一种情况：代码确实是扫到了，可覆盖率的报告却不是按照同一分支生成的。比如CI里测试跑的还是旧代码，coverage的路径跟源码路径凑不到一块，或者有些模块在这条分支里被排除掉了，这些都会让覆盖率和主分支差出一截。碰到这种时候，不要光盯着SonarQube页面上的数字，得回到流水线的日志里去查一下报告到底是怎么生成的。

　　4、质量配置或排除规则不一样

　　如果项目在不同的分支上用了不同的sonar-project配置、不同的质量配置文件，或者某些分支临时加了一些exclusions，那分析结果自然也就会跟着变化。特别是那种多模块的项目，某个模块有没有被纳入扫描，会直接影响到问题的总数和覆盖率的数值。

　　三、分支分析结果怎么排查和统一

　　在排查分支之间的差异时，不要只在页面上比一比问题数量的多少。更稳当的做法，是把代码的版本、扫描时用的命令、配置文件、测试报告，还有对新代码的定义这些项目一项一项去对齐。

　　1、先翻看流水线的日志

　　检查一下实际执行的那几条扫描命令、分支名称、项目key、源码目录、排除规则，还有报告的路径。很多看着不对劲的问题，其实不是出在SonarQube页面上，而是因为CI往里面传参的时候就已经不一致了。

　　2、把项目扫描配置统一起来

　　把公共的配置放到一个固定的地方，不要由着不同的分支各维护一套扫描参数。像质量规则、排除目录、覆盖率报告的路径、测试报告的路径这些，尽量让它们统一，只把确实需要随着分支变化的那点内容交给CI变量去处理。

　　3、同步主分支的代码后再复扫

　　要是功能分支已经很久没有去同步主分支了，两边分析的差距就会越拖越大。可以先做一次合并或者rebase主分支的动作，然后再重新跑一遍测试和扫描，这样就能把由于代码基线过旧而引出的那部分差异给排除掉。

　　总结

　　总的来看，SonarQube分支分析怎么开启、结果为什么和主分支不一致，关键都在于先确认好版本是不是支持，再通过分支参数把扫描结果写到对应的分支里去。结果和主分支不一样，一般都是跟代码的差异、新代码的定义、覆盖率报告、扫描配置，还有CI里面那些变量有关联。在排查的时候，不要只看页面上的结果，要返回到流水线日志和项目配置那里，把代码基线、扫描参数、质量规则和报告路径这些放在一起核对，分支分析的结果才会更加可靠。