一、先确认修改边界
不要从“代码看起来没问题”开始审查。先确认当前分支、工作目录和变更文件,避免把其他任务的修改一起提交。
git branch --show-current
git status --short
git diff --name-status二、阅读完整差异
先看统计,再逐文件阅读差异。重点检查是否出现意外删除、调试输出、硬编码地址或与任务无关的重构。
git diff --stat
git diff --check
git diff -- . ':!package-lock.json'大型锁文件可以单独检查,但不能因为内容太长就跳过依赖变更审阅。
三、按风险分层测试
- 先运行格式化、类型检查或项目已有的静态检查。
- 再运行覆盖本次修改的单元测试。
- 最后运行必要的集成测试或构建。
使用项目已有命令,不要凭空假设测试脚本名称。未运行的检查应明确记录原因。
四、专门检查安全边界
- 输入是否经过校验,错误信息是否泄露密钥、路径或堆栈。
- 文件、网络、数据库和 shell 操作是否限制在必要范围。
- 权限判断是否在服务端执行,而不是只依赖前端。
- 配置和密钥是否通过环境变量或受保护的密钥管理系统注入。
五、提交前验收
git diff --check
git status --short
# 确认测试结果后再提交
git commit -m "describe the focused change"提交信息应说明实际变更,不要用“AI generated”替代功能描述。合并前保留人工审查记录和测试结果。
本文提供通用审查流程,不代表任何项目已经在本机或生产环境完成实测。具体测试命令、分支策略和发布规则以项目文档为准。