GH006报错表明远程分支受保护规则拦截，非Git或权限问题；需通过新建分支→发起PR→审核合并的合规流程解决，禁用强制推送。
push被拒绝：remote: error: GH006: Protected branch update failed
这是 GitHub 上最常见的保护分支拦截报错，本质不是 Git 问题，而是远程仓库策略阻止了直接推送。本地 git push 操作本身完全正确，失败点在服务端校验——比如 main 或 master 被设为「require pull request reviews」或「include administrators」等保护规则。
- 别急着改本地 Git 配置或强行
--force，那只会触发更严格的拒绝（甚至被禁用推送权限） - 先确认目标分支是否受保护：
git remote show origin会显示远程分支状态，但更可靠的是直接打开 GitHub 仓库 Settings → Branches → Branch protection rules - 如果你没有管理员权限，唯一合规路径是：提交到新分支 → 发起 Pull Request → 等审核通过后由有权限者合并
本地已 commit 到 main，但 push 失败怎么办
很多人误以为“已经 commit 到本地 main 就必须推到远程 main”，其实可以零成本切换目标分支。关键不是删 commit，而是重定向推送出口。
- 新建功能分支并把当前 commit 移过去：
git checkout -b feat/login（当前 HEAD 会被自动带上） - 强制重置本地
main到远程一致（避免后续混淆）：git checkout main && git reset --hard origin/main - 然后
git push origin feat/login，再在 GitHub 界面发起 PR，目标选main - 注意：如果本地
main已有多个未同步 commit，用git rebase -i origin/main可交互式挑出要保留的，再 cherry-pick 到新分支
GitLab / Bitbucket 同样报错但提示不同
GitLab 常见报错是 remote: HTTP Basic: Access denied 或 remote: You are not allowed to push code to protected branches；Bitbucket 则可能是 remote: Branch refs/heads/main is protected。底层逻辑一致，但操作细节有差异：
- GitLab：检查项目 Settings → Repository → Protected branches，确认你的角色（Developer 以上才允许推送，Maintainer 才能修改保护规则）
- Bitbucket：Settings → Branch permissions，注意「Merge checks」和「Require approvals」是否启用，且你是否在 approved list 中
- 三者都不支持绕过保护的命令行开关——
git push --force-with-lease在保护分支上依然被拦截，服务器层直接拒绝
CI/CD 提交自动触发 push 时失败
自动化脚本（如 GitHub Actions 中用 git commit && git push 更新版本号）在保护分支上必然失败。这不是权限问题，而是设计使然：保护规则默认禁止所有直接推送，包括机器账号。
- 解决方案不是关保护，而是用 GitHub App Token 或 Personal Access Token 替代默认
GITHUB_TOKEN，并在 token 权限中勾选contents: write - GitLab CI 需在项目 Settings → CI/CD → Variables 中添加
CI_JOB_TOKEN并确保 pipeline 具备developer角色权限 - Bitbucket Pipelines 必须用 repository-specific app password，并在
bitbucket-pipelines.yml中显式声明- export BB_AUTH_STRING="username:app_password"
保护分支机制本身没有 bug，它只是严格执行设定。真正容易被忽略的点是：错误信息里写的「protected branch」不是指分支名，而是指该分支当前被哪条规则锁定——同一条规则可能同时作用于 main、release/* 和 hotfix/*，排查时得看完整匹配模式，不是只盯着分支名。
