Git 提交前检查

为什么要在 git commit 之前看 diff

本地改完就提交，很容易把只在本分支才成立的假设、未处理的异常路径，或一行 SQL 拼接带进仓库。事后在 CI 或线上才发现，回滚和沟通成本都更高。这个技能把审查窗口前移：在你执行提交前，以 git diff 为唯一事实来源，只讨论本次变更引入的问题，而不是把整个文件当代码评审大会。

技能如何跑通一遍

确定范围：优先用你点名的文件或仓库；能从对话上下文推断则用推断结果；否则先汇总各仓库的 git status --short，让你选要审哪一块，避免对着错误范围输出长篇报告。

采集变更：对已暂存用 git diff --cached，未暂存用 git diff，未追踪文件则读全量内容，合并后按文件类型调整侧重点（例如 Java 看空指针与资源泄漏，前端看 XSS 与异步错误，配置看敏感信息与格式，SQL 看注入与索引）。

逐文件审查：按三级输出——🔴 BUG（空指针、越界、资源未关、竞态等）、🟠 风险（硬编码密钥、SQL 拼接、公共 API 签名变更、回归）、🟡 优化（重复代码、命名、魔法值）。必要时读 diff 上下文行，并粗查被改方法的调用方是否受影响。

结论：每个问题带路径与行号、变更引用；最后给出明确的能否提交建议，语气直接但不堆指责。

适用边界

• 只评本次 diff，不会把未改动的历史代码当成新债清单。
• 依赖工作区里真实的 git 状态；若范围说不清，会先停下来让你选仓库，而不是猜。
• 分类表偏 Java / JS / 配置 / SQL；其它类型走通用质量检查，深度会浅一些。