必须通过四层验证：提交原子性（单一语义目标）、测试覆盖（含单元/集成/跨语言契约）、静态检查（禁用危险语法）、人工审查（聚焦权限、SQL、API、并发逻辑）；且需配置分支保护防手滑。
直接合入主分支前，必须确认变更已通过四层验证：提交原子性、测试覆盖、静态检查、人工审查。跳过任意一层，都可能把逻辑错误或安全漏洞带进生产环境。
如何判断一个 commit 是否满足原子性要求
原子性不是指“只改一个文件”，而是指“只解决一个问题”。常见错误是把 UI 调整、接口修改、日志补全混在一个 git commit 里，导致回滚困难、测试范围模糊、审查无焦点。
- 检查
git log -p -n 1输出：是否所有改动都服务于同一语义目标（如“修复 /api/users 返回 500”） - 拒绝包含跨模块修改的 commit，例如同时动了
auth.go和payment.js - 提交信息必须含动词+宾语+上下文，例如
fix: return 401 when token expired (auth middleware)，不能写update something - 若 commit 中有注释掉的调试代码、临时绕过校验的
// TODO remove，视为未完成，不得进入审查队列
预合并 CI 流水线必须检查哪些项
CI 不是走形式，而是拦截真实风险。很多团队只跑单元测试，漏掉关键环节，结果 PR 合并后才发现数据库迁移失败或 API 兼容性断裂。
Cnb Cool Git
下载
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
-
unit test覆盖率 ≥ 80%，且新增代码行必须被覆盖（CI 工具需配置--include-changed模式） -
static analysis必须启用语言级敏感规则：Go 项目禁用unsafe，Python 禁用eval，TS 禁用any类型 -
integration test需调用真实依赖（DB、Redis、下游服务 mock），验证端到端流程，不能只测 stub - 对多语言项目，额外执行
cross-language contract check：比如 gRPC proto 文件变更后，自动比对 Go/TS/Python 生成代码是否一致
人工审查时重点盯哪几类代码模式
自动化工具能发现语法和风格问题，但逻辑漏洞、边界遗漏、权限绕过必须靠人。审查者不是看“有没有 bug”，而是问“这个改动在什么条件下会崩”。
- 任何涉及权限判断的代码，必须检查是否遗漏
else分支或默认拒绝策略（常见于if user.Role == "admin"后无 fallback） - 数据库查询必须确认是否有
WHERE条件、是否加了LIMIT、是否用了参数化防止注入 - 第三方 API 调用必须检查超时设置、重试逻辑、错误码处理（不能只捕获
Exception，要区分 4xx 和 5xx） - 并发相关代码（
goroutine、async/await、锁）必须验证资源释放路径和竞态可能性，尤其注意 defer 是否在正确作用域
为什么 merge 前必须做 branch protection 配置
保护不是防同事，是防自己手滑。即使你写了完整测试、做了三轮审查，git push --force 或误操作 git merge --no-ff 仍可能破坏主分支历史一致性。
- GitHub/GitLab 必须开启
Require pull request reviews before merging，且required_approving_review_count≥ 2 - 启用
Include administrators，避免管理员绕过审查直接推送 - 设置
Dismiss stale pull request approvals when new commits are pushed，防止旧审查被新代码覆盖 - 禁止
Allow force pushes，尤其对main和develop分支；如需重写历史，必须走git revert+ 新 PR
最易被忽略的是：审查通过 ≠ 合并就安全。必须确保 CI 最后一次运行是在最新 main 基础上 rebase 或 merge 的结果，而不是 PR 创建时的快照。否则同事刚合入的修复，你的 PR 可能悄悄把它覆盖掉。
