git push被拒多数因历史不兼容而非权限问题，应先执行git pull origin main同步远程提交；遇冲突需手动解决、git add、git commit后才能push。
git push 被拒时先看错误关键词，别急着改权限
绝大多数 git push 被拒不是权限问题，而是历史不兼容。看到 non-fast-forward、Updates were rejected 或 fetch first 这类提示，说明远程有你没有的提交——Git 在保护你，不是在拦你。
这时候执行 git pull origin main（把 main 换成你的分支名）是最直接有效的动作。它等价于 git fetch origin + git merge origin/main，把远程新 commit 拉下来并合并进本地分支。
常见误区：
- 跳过
git pull直接git push -f—— 会丢掉别人刚推的代码 - 看到
Permission denied (publickey)还去拉取远程 —— 这是 SSH 认证失败，和历史无关 - 用
git pull --rebase后没解决冲突就直接 push —— rebase 中断后必须git add+git rebase --continue才算完成
遇到 merge conflict 怎么安全解决
执行 git pull origin main 后如果报 conflict，说明你和远程改了同一文件的同一段落。Git 把两版内容都标出来，但不会替你决定用哪边。
操作要点：
- 打开带
和 <code>>>>>> origin/main标记的文件，删掉这些标记，只保留最终要的内容 - 保存后必须运行
git add（不能只git add .，容易漏掉未跟踪的新文件） - 接着执行
git commit -m "resolve conflict in README.md"—— 这步不能省，否则 Git 不认为冲突已结束 - 最后再
git push origin main
什么时候能用 git push --force-with-lease
git push --force-with-lease origin main 是唯一相对安全的强制推送方式，但它只适用于明确知道远程没人依赖该分支的场景。
典型适用情况：
- 你刚用
git rebase -i整理了本地提交，需要同步到自己的 feature 分支 - 你用
git commit --amend修改了最新提交，且确认没人基于它开发 - 你在私有分支上重写了历史，团队约定所有人需
git reset --hard origin/branch-name重新拉取
绝对不能用在 main、develop 等集成分支上——哪怕只有一人正在拉取，--force-with-lease 也会失败并提示 stale info，这时就得切回 pull 或 rebase 路线。
远程提示 “branch is currently checked out” 怎么办
这个错误不是你本地的问题，而是远程仓库本身配置不当：它是个非裸仓库（non-bare repo），且当前正检出在 main 分支上。Git 默认禁止向已检出分支推送，防止工作目录和对象库不一致。
如果你是该远程仓库的维护者，修复方式很简单：
- 登录服务器，进入远程仓库目录
- 运行
git config receive.denyCurrentBranch updateInstead（允许覆盖工作树） - 或更规范的做法：重建为裸仓库
git clone --bare /path/to/current/repo.git /new/bare/repo.git，然后更新远程 URL
如果你只是协作者，那就别碰服务器配置，换用 PR 流程：推到新分支（如 git push origin HEAD:feature/fix-login），再在平台发起合并请求。
真正容易被忽略的是：很多团队把“推送被拒”当成网络或权限问题来查，结果花半天调 SSH、换 token，最后发现只是少了一次 git pull。历史同步这件事，没有捷径可绕。
