Git push被拒绝主因是本地与远程提交历史不兼容，需先git pull或fetch同步；常见于他人已推送、本地基于旧HEAD提交或初始化时远程已有文件（如README.md）。
Git push 被拒绝，90% 的情况不是权限或网络问题，而是本地分支和远程分支的提交历史不兼容——必须先同步再推送，不能跳过 git pull 或 git fetch 直接硬推。
为什么 git push origin main 会报 rejected（non-fast-forward）
Git 拒绝推送的核心原因是：远程分支的最新提交不在你的本地分支历史中（即远程有你没有的 commit）。这通常发生在别人先 push 了、你本地又基于旧 HEAD 提交了新东西，或者你初始化仓库时漏掉了远程已存在的文件（比如 README.md）。
此时 Git 认为直接覆盖会丢失他人工作，所以强制阻止。错误信息里常带关键词：non-fast-forward、failed to push some refs、Updates were rejected。
- 不是权限不足（那种错会明确提示
Permission denied或Authentication failed） - 不是 SSH 配置错了（那会在
git push前就卡在连接阶段） - 也不是 .git 文件损坏（那会触发各种其他命令失败）
git pull 后出现 merge conflict 怎么安全处理
执行 git pull origin main 后如果提示 conflict，说明你和远程改了同一文件的同一段落。Git 不会自动决定用谁的，得你手动裁决。
常见操作顺序：
- 用编辑器打开标有
和 <code>>>>>> origin/main的文件，删掉冲突标记，保留最终要的内容 - 保存后执行
git add标记为已解决 - 执行
git commit -m "resolve conflict in README.md"（不要省略 commit） - 再
git push origin main
注意：git pull --rebase origin main 可以避免生成 merge commit，但要求你本地没有依赖远程 commit 的后续操作；如果不确定，优先用默认 git pull。
什么时候能用 git push -f（强制推送）
强制推送 git push -f origin main 是把本地分支“强栽”到远程，抹掉远程所有你不含有的提交。它只适用于以下明确场景：
在 OpenClaw 中管理 GitHub 仓库、Pull Request、Issue 与工作流。适用于审查 PR、管理 Issue、自动化 GitHub Actions、同步仓库等场景。
- 你是唯一开发者，且远程分支没人依赖（比如个人练习仓库的
dev分支） - 你刚重写了提交历史（如用
git rebase -i或git commit --amend），需要同步修正 - 团队明确约定某次推送后所有人需
git reset --hard origin/main重新拉取
在协作项目中对 main、develop 等集成分支执行 -f，大概率导致队友 git pull 失败、本地历史断裂、CI 流水线异常——这不是捷径，是事故导火索。
初次推送被拒：本地无 README 但远程有怎么办
新建仓库时勾选了 “Add a README file”，而你本地 git init 后直接 add + commit + push，就会因缺少该文件被拒。错误提示可能含 refusing to merge unrelated histories。
正确做法是先拉取并允许合并无关历史：
git pull origin main --allow-unrelated-histories
然后 Git 会把远程的 README.md 合并进来（可能触发一次空冲突，按提示 git add README.md && git commit 即可）。之后再 git push origin main 就能通过。
别删 .git 重来——那是放弃所有本地 commit 记录，除非你确认没任何有价值改动。
真正容易被忽略的点：很多人以为 git pull 就是“更新代码”，其实它本质是 git fetch + git merge（或 git rebase）。如果你从没运行过 git fetch origin，就不知道远程到底多了什么；没看 git log --oneline --graph --all，就无法判断是否真存在分叉。拒绝推送不是障碍，是 Git 在提醒你：该看看历史图谱了。
