代码审查必须通过pr工作流固化在合并前，而非直接push到main；其核心在于分支保护、小粒度提交和结构化评论，而非工具本身。
代码审查不是“看一眼就点 Approve”，而是靠 Pull Request 工作流把审查动作固化在合并前的必经环节。关键不在工具，而在分支策略、提交粒度和评论习惯。
为什么直接 push 到 main 会跳过审查
Git 本身不提供审查机制，git push origin main 是纯数据同步操作，没有任何拦截或提示。审查必须依赖托管平台（GitHub/GitLab/Bitbucket）的 PR 机制——它强制要求：源分支 ≠ 目标分支，且合并需经 Web 界面发起。
常见错误现象：remote: error: GH006: Protected branch update failed，这是因为你试图绕过保护规则直接推送；但更隐蔽的问题是：团队成员为图快，在本地 git checkout main 后直接改、直接 git commit，再 git push，结果审查完全缺失。
- 所有开发必须从受保护分支（如
main或develop）拉出新分支，例如git checkout -b fix/login-timeout main - 目标仓库需开启分支保护规则：要求 PR、至少 1 个批准、CI 通过后才允许合并
- 不要在本地
main上做任何修改——它只应作为同步锚点
如何写一个能被高效审查的 PR
标题和描述不是形式主义，它们决定别人是否愿意点开、花多少时间读你的变更。低效 PR 的典型表现是：标题为 Update files，描述为空，Diff 超过 300 行，混着样式调整、逻辑修复和日志增删。
使用场景：当你修复一个登录超时 bug，同时顺手格式化了相邻几行代码，这两类修改应拆成两个 PR。
- 标题用动词开头，明确作用域，例如
fix(auth): reduce login timeout from 30s to 10s - 描述第一行空着，第二行起写「为什么改」（引用 issue 号如
#123），第三行起写「怎么改」（不重复代码，讲清思路） - 单个 PR 只解决一个问题，代码变更控制在 200 行以内；超过则考虑拆分或先沟通
- 如果涉及接口变动，附上请求/响应示例；如果是 UI 改动，贴截图或录屏链接
reviewer 应该关注什么，而不是什么
审查不是挑语法毛病，也不是逐行确认你有没有少写分号。重点应落在「这个改动是否让系统更可靠、更可维护、更符合设计约束」。
容易踩的坑：Approve 前只扫了一眼 diff，没运行本地测试；或看到 CI 通过就直接点，结果发现 CI 没覆盖边界 case。
- 必查：是否新增了未处理的异常路径？是否修改了公共函数签名却没更新调用方？
- 必查：是否有硬编码（如
"https://localhost:8080"）、魔法数字（如if (status == 4)）或调试残留（如console.log）？ - 不必深究：变量命名是否“足够语义化”（除非明显误导），缩进用空格还是 tab（交给 pre-commit 钩子）
- 遇到不确定的设计选择（如缓存策略），别直接否决，用评论提问：
@author can we use Redis here instead of in-memory cache? Latency may spike under load.
合并前最后一步常被忽略：rebase 还是 merge？
这不是风格问题，而是影响历史可读性和回滚成本的技术选择。GitHub 默认用 merge，生成一个合并提交；rebase 则把你的提交线性重放到目标分支顶端。
性能与兼容性影响：rebase 后的提交 SHA-1 全变，如果别人已基于你旧分支开发，他们必须 git rebase --onto 重新挂载，极易出错；而 merge 提交保留原始上下文，适合多人并行评审的场景。
- 团队内部协作（同一仓库，分支生命周期短）：优先用
rebase，保持历史干净 - 开源项目或跨团队贡献（Forking 工作流）：必须用
merge，避免破坏贡献者本地历史 - 无论选哪种，合并前务必
git fetch origin && git rebase origin/main（或git merge origin/main），确保无冲突且含最新 CI 结果
最复杂也最容易被忽略的一点：审查不是一次性的点击动作，而是围绕 PR 的持续对话。有人提 comment，你 push 新提交后，必须手动在评论里回复 Done 或 Addressed，否则 reviewer 很可能错过更新——GitHub 不会自动标记“已修复”。
