SonarQube怎么配置SCM代码归属信息 SonarQube分析后缺少代码作者信息如何排查

代码扫描完成后，文件里能看到问题，却找不到相关行的作者，排查时就少了提交记录这个线索。SonarQube的代码归属信息来自版本控制历史，执行扫描的账户不能直接代替代码作者。下面以Git仓库和SonarScanner CLI为例，说明SCM配置与作者缺失的处理方法，网页操作采用英文界面名称。

一、SonarQube怎么配置SCM代码归属信息

Git项目通常可以自动识别SCM，不必逐个填写作者姓名。配置时要让扫描器拿到仓库信息和完整历史，填写仓库地址链接本身并不能补出代码归属。

1、准备带历史记录的源码

直接下载源码压缩包，或把代码复制进另一个目录，可能只留下文件内容。扫描时需要保留仓库元数据，容器和流水线中的分析目录也应满足这一要求。以下Git检查命令需在已安装Git的环境执行。

①使用【git clone】完整检出仓库，不设置【--depth】。

②进入分析目录，执行【git rev-parse--show-toplevel】，核对仓库根目录。

③执行【git rev-parse--is-shallow-repository】，查看是否返回【false】。

2、检查SCM分析参数

①打开工程根目录的【sonar-project.properties】。

②检查【sonar.scm.disabled】，删除关闭设置，或设为【false】。

③自动识别失败时，添加【sonar.scm.provider=git】，保存文件。

④检查流水线的扫描命令，移除冲突的【-Dsonar.scm.disabled=true】。

命令行参数可以覆盖配置文件里的设置，文件改对了，流水线仍可能继续关闭SCM。指定Git类型只是在告诉扫描器使用哪种SCM，缺失的提交历史仍需从仓库取得。

3、重新分析并核对结果

①保留已有服务器地址、项目标识和认证配置，执行【sonar-scanner】。

②查看本次扫描日志，检查【SCM】相关记录。

③待服务端处理完成，打开项目的【Code】，进入已提交的源文件，查看行旁提交信息。

二、SonarQube分析后缺少代码作者信息如何排查

整批文件缺少作者，和个别文件缺少作者，检查方向不同。排查应使用实际扫描工作区，开发电脑上的仓库正常，并不能证明流水线检出的副本也正常。

1、按扫描警告定位文件

①打开本次流水线的扫描日志。

②搜索【Missing blame information】、【Shallow clone】和【Could not find ref】。

③记录警告对应的文件路径，在扫描工作区找到该文件。

这些记录分别提示归属读取、历史深度或提交引用存在问题。日志已经指出某个文件时，可以先检查该文件，避免反复调整全部项目参数。若完全没有SCM处理记录，则回看SCM是否被禁用或识别失败。

2、补齐浅克隆历史

流水线为了缩短检出时间，可能只拉取近期提交。SonarQube发现浅克隆后会跳过归属信息读取，源码能够编译也不能说明历史已经完整。

①在扫描目录执行【git rev-parse--is-shallow-repository】。

②返回【true】时，执行【git fetch--unshallow】。

③将流水线的检出深度改为完整历史，再次执行【sonar-scanner】。

3、检查文件是否已提交或被改写

①在扫描工作区执行【git status--short】。

②核对目标文件是否未跟踪或存在未提交修改。

③执行【git blame-e--src/example.c】，将示例路径替换为目标文件路径。

④在与目标提交一致的干净工作区重新分析。

新生成的文件没有历史记录，构建期间改写的行也可能无法取得完整归属。扫描前格式化、替换占位内容或复制其他版本源码，都应与工作区状态一起核对，不能把未提交内容当作已有作者记录。

4、临时重新读取全部归属

历史和工作区已经核对无误，旧文件仍缺少信息时，可以尝试重新加载全部文件的归属数据。该参数用于本次排查，分析时间可能增加，不宜一直保留。

①在本次扫描命令中加入【-Dsonar.scm.forceReloadAll=true】。

②执行扫描，核对问题文件的日志与作者信息。

③排查完成后，移除【-Dsonar.scm.forceReloadAll=true】。

三、代码作者信息如何对应到SonarQube用户

代码行已经显示作者，问题仍未分配到对应用户时，应检查账户关联。作者数据读取和用户匹配是不同环节，修改用户资料不能修复缺失的仓库历史。

1、关联提交邮箱与用户账户

①以管理员身份点击【Administration】→【Security】→【Users】，找到目标用户。

②打开用户【Actions】中的三点菜单，选择【Update(SCM)details】。

③在【SCM Accounts】旁点击【Add】，填写实际提交邮箱，再点击【Update】。

④核对其他用户，避免重复关联同一个SCM账户。

关联信息用于帮助SonarQube识别提交者。公司账号邮箱与Git提交邮箱不一致时，可以添加对应的SCM账户，填写时应以提交记录为准，不能只看当前登录名。

2、核对历史提交中的身份

修改本机Git姓名和邮箱，会影响后续提交，不会自动改写已有记录。SonarQube使用的Git实现也不支持通过.mailmap统一归属邮箱，核对身份时应查看原始提交信息。

①执行【git blame-e--src/example.c】，记录目标行的提交号。

②执行【git show-s--format=%ae提交号】，查看原始作者邮箱。

③对照用户的【SCM Accounts】，补充遗漏的历史邮箱。

总结

SCM信息让代码问题能够与提交记录联系起来，但作者归属只能作为追查线索，不能直接等同于问题责任。处理SonarQube怎么配置SCM代码归属信息SonarQube分析后缺少代码作者信息如何排查时，保留完整历史和稳定的扫描工作区，比单纯添加作者姓名更有帮助。团队更换邮箱、调整检出方式后，也应检查归属是否仍然对应。留下一份缺失文件清单和扫描日志，便于比较修改前后的结果。希望这些方法能帮助大家把代码分析与提交记录对照清楚。