分支保护（Branch Protection），是代码托管平台（GitHub、GitLab 等）上的一条仓库规则：给指定分支（几乎总是 main）加上“不许直接推送”的限制，任何改动都必须走合并请求（Pull Request / Merge Request），并且满足你设定的条件才允许合并。
打个比方。 main 是已经包装好、随时能发货的成品仓。分支保护就是成品仓那扇门：不能自己拿钥匙进，得有同事刷卡陪同（评审通过），还得过安检机（自动化检查全绿），门才开。你可以在旁边的车间（功能分支）随便折腾，但货要进成品仓，必须走这道流程。
关键点在于：分支保护管的不是“谁能改代码”，而是“改代码必须经过什么”。
给智能体划线，怎么设才不是摆设：
1. 核心开关是“合并需要评审 + 需要状态检查通过”，而不只是勾一句“禁止强制推送”。只禁 force push，等于只锁了后门，正门还敞着。
2. 规则要覆盖管理员。很多平台有“是否对管理员生效”的选项，不勾上，一条 admin bypass 就能让整套规则归零——这恰恰是最常见的“形同虚设”。
3. 状态检查必须真的会失败。编译、单元测试、静态检查、类型检查，至少要有一项跑在合并前。如果检查永远绿灯，或者允许“检查失败也能合”，那它只是装饰。
4. 设必需评审人数，并开启“新提交会作废旧批准”。否则先批准、再偷偷追加改动，评审就白做了。
5. 同时禁止强制推送和删除该分支，防止历史被覆盖。
6. 给智能体单独的身份和最小权限：机器人账号或专用令牌，只允许开分支、提合并请求，不允许直接推 main、不允许自行合并。它干得越多，这条线越要硬。
7. 能用组织级规则（ruleset）就别逐仓库手勾，否则新开的仓库天然裸奔。
和相邻概念的区别：
| 概念 | 管什么 | 类比 |
|---|---|---|
| 分支保护 | 对这条分支允许哪些操作 | 门禁 |
| 代码评审 | 改动有没有被人看过 | 签字 |
| 持续集成（CI） | 改动跑不跑得通 | 安检机 |
| 角色权限（RBAC） | 你是谁、属于哪个组 | 工牌 |
分支保护本身不评审、不测试，它是强制前面几件事必须发生的机制。各家平台的选项名称和默认行为不完全一样，具体以官方文档为准。
实际意义： 有了能干活的编码智能体之后，人的角色从“写代码”偏向“审代码”，信任的基础也该从“相信某个人的自觉”换成“相信流程”。一条设对了的分支保护，成本几乎为零，却能在凌晨三点挡住一次把半成品推上线的自动提交——对你写的程序，对用户用的产品，都是最便宜的一道保险。