安全创建分支必须绕开裸调API，走拉取请求前置流程或受保护分支策略触发路径：GitHub优先用PR方式，Azure DevOps需带X-VSS-ForceMsaPassThrough头，GitLab需developer权限且显式传protected=true。
直接调用 Git API 创建分支本身很简单，但要让分支创建行为可审计、权限变更可追溯、操作风险可拦截，必须绕开裸调 git branch 或简单 POST /repos/{owner}/{repo}/git/refs 的思路——真正卡住关键点的是权限校验时机和日志埋点位置。
如何用 GitHub/GitLab/Azure DevOps API 安全创建分支
单纯发一个 POST /repos/{owner}/{repo}/git/refs 请求能创建分支，但绕过了所有权限控制（比如某人本无写权限，却通过 API 直接推 ref）。真正安全的做法是：始终走「拉取请求前置流程」或「受保护分支策略触发的创建路径」。
- GitHub：优先用
POST /repos/{owner}/{repo}/git/refs仅限拥有push权限的 token；更推荐先 fork，再用POST /repos/{owner}/{repo}/pulls提 PR，由 CI/策略自动创建目标分支 - Azure DevOps：必须用
POST https://dev.azure.com/{org}/{proj}/_apis/git/repositories/{repoId}/refs，且请求头需带X-VSS-ForceMsaPassThrough: true，否则权限继承逻辑不生效 - GitLab：
POST /api/v4/projects/:id/repository/branches要求 token 至少有developer角色，且目标分支若受保护，需显式传protected=true - 注意：所有平台对
ref名称都有校验（如不能含空格、不能以.开头），失败时返回422 Unprocessable Entity，不是权限问题，别误判
分支权限变更必须捕获的三个审计事件
权限不是“设完就完”，而是动态生效的。审计重点不在「谁点了保存按钮」，而在「哪次 Git 操作实际受该权限影响」。
-
push到受保护分支失败时，GitHub 返回403 Forbidden+ 提示refusing to allow a GitHub App to create or update workflow files—— 这类错误必须被日志系统捕获并关联到原始权限设置时间戳 - Azure DevOps 中，用户执行
git push origin feature/x后，服务端会查Contribute权限，但审计日志只记「权限检查结果」，不记「检查依据的策略规则 ID」，需额外调用GET /_apis/policy/configurations补全上下文 - GitBucket 的
Collaborator.scala里权限判断走的是 RBAC 模型，但日志中audit级别默认不记录「策略匹配过程」，需手动在AccountService.scala的checkPermission方法里加logger.info(s"Audit: $user checked $permission on $resource")
为什么不能只监听 webhook 的 create 事件
create webhook 确实能捕获分支创建动作，但它不包含「谁批准了这次创建」「是否绕过策略」「是否关联 PR」等关键上下文，纯靠它做审计等于只看门牌号，不管进屋的人有没有钥匙。
- GitHub 的
createevent payload 里没有actor的 token scope 信息，无法判断是个人 token 还是 GitHub App token 发起的 - Azure DevOps 的
git.pushevent 会带commits列表，但分支创建本身可能没 commit（空分支），此时 event 根本不触发 - GitLab 的
branch_createdevent 缺少「分支保护规则是否启用」字段，而这是权限生效的前提条件 - 正确做法：把 webhook 当触发器，再主动查 API 补全数据——比如收到
create后，立刻调GET /repos/{owner}/{repo}/branches/{branch}拿protected状态，再查GET /repos/{owner}/{repo}/branches/{branch}/protection
真正的难点不在调哪个 API，而在于把「权限定义」、「权限执行」、「权限审计」三件事的时间戳对齐——比如 Azure DevOps 设置分支策略后，策略生效延迟可能达 30 秒，这期间发生的 push 操作仍按旧策略判定，但日志里却记成新策略已启用。
