本地提交前用 git diff --cached 审查暂存区代码，结合 git status 检查误加文件，-w 忽略空格聚焦逻辑，启用 pre-commit 钩子保障格式，pr 描述需含 type/动机/验证方式，分支名用 type/scope/description 格式，评审时重点查依赖升级、副作用、函数签名变更及可逆性。
怎么在 Git 提交前做有效的 Code Review
Code Review 不是等 git push 完再看别人仓库里的 PR，真正高效的一轮评审，得发生在本地提交前。这时候你手上有完整的上下文，改了什么、为什么这么改、有没有漏掉测试，都一清二楚。
实操建议：
- 用
git diff --cached看即将提交的变更（也就是git add后还没git commit的内容），这是最干净的 review 切入点 - 别跳过
git status—— 有时候误加了node_modules/或临时调试日志，就藏在未暂存文件里 - 对关键逻辑，用
git diff -w忽略空格变化，聚焦语义差异；但注意：-w会掩盖缩进错误，CI 可能报错 - 如果团队有 pre-commit 钩子（比如
prettier+eslint），确保它已启用 —— 否则格式问题会干扰逻辑评审
PR 描述写什么才不算敷衍
“修复 bug” 或 “优化性能” 这类描述等于没说。Reviewer 打开 PR 第一眼看不到动机，就会卡住或直接问你，拖慢整个流程。
实操建议：
- 第一行用
feat:/fix:/refactor:开头（和团队约定一致即可），控制在 50 字内，说明「做了什么」 - 正文必须包含「为什么」：
Before状态下哪里出问题（可贴错误日志片段，如TypeError: Cannot read property 'id' of null），After如何解决 - 附上可验证方式：比如 “本地运行
yarn test:unit --testNamePattern=useAuth通过”，或 “访问/admin/users?role=editor页面不再白屏” - 避免写 “详见 commit log” —— PR 描述是独立文档，不是 commit 的索引
Git 分支命名怎么避免混乱
分支名不是个人备忘录。fix-bug-2024、my-new-feature 这类名字在多人协作中毫无信息量，合并时连自己都记不清当初改了啥。
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
实操建议：
- 统一用
type/scope/description格式，例如：fix/auth/token-expiry、feat/dashboard/export-csv -
type限定为几个常用值：feat、fix、chore、docs、refactor（不推荐hotfix，它本质还是fix） -
scope写模块或功能域，不是文件路径（用auth，别用src/utils/auth.js） - 禁止用数字编号代替描述，比如
fix/12345—— Jira 编号放 PR 描述里，分支名要自解释
Review 时怎么快速定位风险点
没人会逐行读完 2000 行 diff。真正需要关注的是高风险模式：状态变更、副作用调用、边界条件、第三方依赖升级。
实操建议：
- 先扫
package.json：如果有"lodash": "^4.17.21"→"lodash": "^4.18.0"，查 CHANGELOG 看是否含 breaking change - 搜
localStorage、sessionStorage、fetch、setTimeout这类易出错关键词，确认是否有异常处理或清理逻辑 - 对比前后函数签名：如果改了
getUser(id)→getUser(id, options)，检查所有调用处是否传了默认值或适配了新参数 - 留意新增的
console.log、debugger、console.table—— 它们不该出现在提交代码里，哪怕只是临时调试
最常被跳过的其实是「合并后行为是否可逆」：比如删了一个 API 路由，有没有 404 fallback？改了数据库 schema，migration 脚本能否回滚？这类问题往往到上线才发现。
