必须用分支隔离审查，因为直接推送到main会跳过审查导致高风险：17%的未审查提交48小时内引发告警，63%源于未发现的边界错误；分支隔离将“谁改了什么”与“谁确认过”绑定，pr/mr机制仅对分支差异生效，main不承载审查上下文。
为什么必须用分支隔离审查，而不是直接改 main
直接在 main 上提交代码，等于跳过审查环节，风险是实时的：CI 可能没跑完、测试可能漏掉、逻辑冲突可能被掩盖。2025 年某 SaaS 团队统计显示，未走分支审查流程的提交中，17% 在 48 小时内引发线上告警，其中 63% 源于未被发现的边界条件错误。
分支隔离的本质不是“多一道手续”，而是把「谁改了什么」和「谁确认过它」绑定在一起。GitHub/GitLab 的 PR/MR 机制只对分支间差异生效，main 本身不承载审查上下文。
- 所有新功能、修复、配置变更，必须基于
develop（或main，取决于工作流）创建独立分支，命名格式为feature/REQ-123-login-refactor或hotfix/BUG-456-null-pointer - 禁止使用
git push origin main直推主干；仓库需开启分支保护规则，强制要求 PR + 至少 1 名 reviewer 批准 + CI 通过才允许合并 - 本地开发完成后，先
git rebase develop（非merge），确保提交线性干净，减少后续审查时的噪声
PR 描述里哪些字段真正影响审查效率
空泛的标题如 “修复登录问题” 或 “更新依赖” 会让 reviewer 花 3 分钟猜意图。实际项目中，高通过率的 PR 共享一个特征：关键信息前置、可验证、有上下文锚点。
必须包含以下三项，缺一不可：
-
What changed：精确到文件+行号范围（例如：src/auth/service.ts:42–67），避免笼统说“调整了认证逻辑” -
Why it matters：关联需求 ID（REQ-123）或 bug 单（BUG-456），并说明影响面（如“影响所有 OAuth2 登录路径，不影响短信登录”） -
How to verify：给出可执行的验证步骤（例如：curl -X POST /api/v1/login -d '{"provider":"github"}'，预期返回200+ token 字段）
模板可放在 .github/pull_request_template.md，但禁止让开发者删空占位符——CI 流程应校验这三项是否非空，否则拒绝触发构建。
合并前必须检查的三个技术细节
即使 PR 已获批准，合并前仍可能埋雷。常见疏漏不是逻辑错误，而是协作链路上的断裂。
- 确认
git status显示工作区干净，且git log --oneline HEAD...origin/develop输出与 PR diff 完全一致（防止本地未 push 的提交被意外合入） - 检查 CI 状态是否为最终态：不是“checks queued”，而是“
build passed”、“test coverage ≥ 85%”、“lint OK” 全部绿色打钩；某些平台会缓存旧状态，需手动刷新 - 若涉及数据库迁移或 API 变更，确认
migration/20260723_add_user_status.sql或openapi/v2.yaml文件已随 PR 提交，且版本号递增（例如从v2.3到v2.4）
reviewer 容易忽略但至关重要的审查点
多数 reviewer 关注业务逻辑和单元测试，但真正导致线上事故的，常是那些“看起来没问题”的细节。
- 检查日志语句是否含敏感字段（如
logger.info("user: %s, token: %s", user.id, token)——token必须脱敏或禁用） - 确认新增的第三方 SDK 调用是否加了超时和 fallback（例如
axios.get(url, { timeout: 3000 })，而非裸调用） - 观察是否有隐式状态依赖：比如函数内部读取了全局
process.env.NODE_ENV，但未在测试中覆盖production场景
这些点不会在 diff 里高亮，需要 reviewer 主动展开相关上下文文件查看。建议在团队内部共享一份 review-checklist.md，每次审查前快速过一遍——它比任何自动化工具都更早拦住低级但致命的问题。
