远程分支代码质量审核必须绑定pr/mr的ci流水线，通过静态扫描、单元测试、格式检查等门禁拦截低质变更，并强制启用分支保护规则；本地pre-commit易被跳过且无法覆盖协作场景，故服务端强制执行才是可靠方案。
Git 本身不检测代码质量，必须靠外部工具链集成才能实现“远程分支代码质量审核”——直接在 PR/MR 触发时拦截低质变更。
PR/MR 触发时自动运行质量检查
所有质量门禁必须绑定到 Pull Request 或 Merge Request 的 CI 流水线，而不是仅在 git push 到远程分支时运行。否则开发者可能绕过检查、或在本地未复现问题。
- GitHub：在
.github/workflows/ci.yml中配置on: pull_request，而非on: push - GitLab：使用
rules:匹配merge_requests事件，避免只监听push - 关键动作必须包含：静态扫描（如
sonar-scanner）、单元测试（npm test或pytest）、格式检查（prettier --check） - 任一检查失败，PR/MR 状态应标记为 ❌，且禁止合并（需在平台设置 branch protection rules 强制启用）
为什么不能只依赖本地 pre-commit hook
本地 pre-commit 钩子容易被跳过（git commit --no-verify），也无法覆盖协作场景中的“别人推的代码”。远程分支的质量控制必须由服务端强制执行。
Github Stars Analyzer
下载
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
- 团队中总有新人或临时协作者忽略钩子安装步骤
-
pre-commit无法验证跨文件影响（例如 API 变更未同步更新文档或客户端） - CI 环境能提供统一的 Node/Python/Java 版本和依赖，避免“在我机器上能跑”的陷阱
- 真实质量数据（如覆盖率下降、重复代码率上升）只能从 CI 日志中聚合，用于后续度量
SonarQube 集成的关键配置点
如果用 SonarQube 做远程质量审计，光跑扫描不够，必须设好质量门（Quality Gate）并关联到 PR 分析结果。
- 确保 CI 中调用
sonar-scanner时传入-Dsonar.pullrequest.key=xxx和-Dsonar.pullrequest.branch=feature/xxx，否则无法做增量分析 - 质量门里至少勾选：新增漏洞数 ≤ 0、新增覆盖率 ≥ 当前分支平均值、新增重复块 ≤ 0
- 不要开启“全局质量门”，而要用项目级自定义门——不同模块容忍度不同（如前端可放宽复杂度，后端严控安全漏洞）
- 扫描结果必须回传到 PR 页面（GitHub/GitLab 插件支持），否则审查者看不到具体哪行触发了
critical问题
真正卡住质量的不是工具是否装了，而是“谁在什么环节看到什么结果、能否阻止合并”。远程分支审核失效，往往是因为质量检查没进 PR 流程，或者质量门配置成了摆设——比如允许新增 5 个高危漏洞还标 ✅。
