Git push被拒主因是权限不足或分支保护规则触发，需先用git remote show origin查推送权限，再进平台Settings→Branches确认保护规则，严禁强制推送，应走PR/MR流程。
git push 被拒绝：先查权限，再看分支状态
远程推送失败不是网络或命令写错，八成是权限或分支保护规则在起作用。尤其在 Gitea、GitLab 或 GitHub 上启用分支保护后，git push 会直接被拦截，连错误提示都可能被精简成 remote: Permission denied 或静默失败。
实操建议：
- 用
git remote show origin查看当前远程的推送权限范围（注意输出中Push URL是否可写，以及HEAD branch是否受保护） - 访问代码平台网页端，打开仓库 → Settings → Branches / Protected Branches，确认目标分支（如
main）是否启用了「Require pull request reviews」或「Include administrators」等限制 - 若你有管理员权限但仍被拒，检查是否勾选了「Allow force pushes」——某些团队禁用该选项后，
git push --force会直接失败，而非报错 - 临时绕过？别硬推。正确做法是走 PR/MR 流程，哪怕只有一行修改
git checkout -b feature/x --track origin/feature/x 失败的真正原因
报错 fatal: 'origin/feature/x' is not a valid branch name，不一定是拼写错了，更可能是远程根本没这个分支，或者它存在但 Git 本地缓存里没有记录。
常见场景：
- 同事刚在网页端创建了
feature/x，但你没执行git fetch origin，本地origin/feature/x还不存在 - 分支名含斜杠（如
feature/login-v2），但远程仓库配置了路径白名单，只允许feature/*，而你输成了feature/login-v2（注意末尾无空格） - 使用 SSH 协议时，远程地址写成
git@host:user/repo.git，但平台实际要求 HTTPS 地址才能读取分支列表（Gitea 某些版本有此行为）
验证方法：运行 git ls-remote --heads origin | grep feature，真实看到远程有哪些分支，比凭记忆或网页刷新更可靠。
分支保护规则下，如何安全地更新已合并的旧特性分支
团队开了「删除已合并分支」自动清理，但你的 feature/search 分支刚被合入 main，还没来得及拉取最新 main 做后续开发，远程分支就被删了——这时 git pull origin feature/search 会报错 fatal: couldn't find remote ref feature/search。
这不是数据丢失，只是追踪关系断了。恢复方式很简单：
- 先确保本地分支还存在：
git branch --contains HEAD确认feature/search仍在 - 重新建立追踪：
git branch --set-upstream-to=origin/main feature/search（如果要对齐主干） - 或从头拉新分支：
git checkout -b feature/search-new origin/main，再 cherry-pick 你需要的提交（git cherry-pick abc123） - 切忌用
git reset --hard origin/main直接重置——会丢掉你本地未推送的修改
权限配置容易被忽略的两个细节
很多团队把权限设完就以为万事大吉，结果某天发现 CI 流水线跑不通，或者新成员 clone 不下来，问题往往出在两处：
-
git config --global user.email必须和代码平台账户邮箱完全一致（包括大小写），否则某些企业版 Git 服务器（如 Azure DevOps）会拒绝认证，报401 Unauthorized而非明确提示 - SSH 密钥未绑定到所有需要的账号：比如你在 GitHub 用 key-A，在公司 Gitea 用 key-B，但
~/.ssh/config里没为不同 host 指定 IdentityFile，Git 会默认用 key-A 尝试连接 Gitea，导致权限拒绝
复杂点在于：分支保护规则本身不报错，它只沉默拦截；而权限配置错误却常表现为“看似能连上，但操作受限”。遇到诡异的推送/拉取失败，优先翻这两处，比重装 Git 有用得多。
