基于Git API的自定义分支创建与权限审计系统开发-git-PHP中文网

安全创建分支必须绕开裸调api，走拉取请求前置流程或受保护分支策略触发路径：github优先用pr方式，azure devops需带x-vss-forcemsapassthrough头，gitlab需developer权限且显式传protected=true。

基于git api的自定义分支创建与权限审计系统开发

直接调用 Git API 创建分支本身很简单，但要让分支创建行为可审计、权限变更可追溯、操作风险可拦截，必须绕开裸调 git branch 或简单 POST /repos/{owner}/{repo}/git/refs 的思路——真正卡住关键点的是权限校验时机和日志埋点位置。

单纯发一个 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 操作实际受该权限影响」。

帮助用户永久删除 Git 仓库历史中的文件，适用于用户提及 “git filter-repo” 等场景。

下载

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")

create webhook 确实能捕获分支创建动作，但它不包含「谁批准了这次创建」「是否绕过策略」「是否关联 PR」等关键上下文，纯靠它做审计等于只看门牌号，不管进屋的人有没有钥匙。

GitHub 的 create event payload 里没有 actor 的 token scope 信息，无法判断是个人 token 还是 GitHub App token 发起的
Azure DevOps 的 git.push event 会带 commits 列表，但分支创建本身可能没 commit（空分支），此时 event 根本不触发
GitLab 的 branch_created event 缺少「分支保护规则是否启用」字段，而这是权限生效的前提条件
正确做法：把 webhook 当触发器，再主动查 API 补全数据——比如收到 create 后，立刻调 GET /repos/{owner}/{repo}/branches/{branch} 拿 protected 状态，再查 GET /repos/{owner}/{repo}/branches/{branch}/protection