刚解决冲突不能直接push，必须先git add暂存、git commit生成有效合并提交，并检查远程是否已被他人更新，否则因历史分叉触发non-fast-forward拒绝。
合并远程分支后出现冲突，解决完不能直接 git push —— 你得先确认本地分支是否已真正完成合并、有没有遗漏暂存、是否被其他人抢先推送过新提交。否则大概率触发 non-fast-forward 拒绝。
为什么刚解决完冲突还推不上去
常见错误是：编辑完冲突文件 → 忘记 git add → 直接 git commit → 发现没生成合并提交 → 或者虽然 commit 了，但远程分支在这期间已被别人更新。
- Git 不会自动把已修改但未
git add的文件纳入合并提交 -
git status显示 “all conflicts resolved” 并不等于“已暂存”，要看有没有出现在Changes to be committed区域 - 即使你本地 commit 成功，若远程
origin/main已有新提交（比如 CI 自动 merge 或同事刚 push），你的 push 仍会被拒绝
解决冲突后推送前必做的三步检查
别跳步骤，每一步都对应一个典型失败点：
- 运行
git status，确认所有冲突文件都在Changes to be committed下，且没有残留的Unmerged paths - 运行
git log --oneline -n 5，检查最新一条是不是你刚做的合并提交（含Merge branch 'origin/dev'这类信息） - 运行
git fetch origin main（假设目标是 main），再执行git status -v，看是否有 “Your branch is behind 'origin/main'” 提示 —— 如果有，说明必须先git pull或git merge origin/main再试
推送时被拒绝：non-fast-forward 怎么办
这不是权限问题，是历史分叉了。不要立刻 --force，先判断分叉来源：
- 如果只是别人多 push 了一次（比如 CI 合并了一个 PR），用
git pull --rebase拉取并变基重放你的合并提交（注意：这会改写你本地的合并提交哈希） - 如果你的合并提交里包含多人协作的关键逻辑（比如修复了线上 bug），建议改用
git pull（默认 merge），生成一个三方合并提交，保留原始上下文 - 只有在确定无人基于你的本地提交继续开发时，才考虑
git push --force-with-lease origin main；--force无条件覆盖，风险极高
合并提交后如何验证推送结果
推送成功不等于代码正确合入。尤其当使用 --rebase 时，原始合并提交已消失，CI 可能不会触发构建：
- 去 GitHub / GitLab 页面刷新目标分支的
Commits列表，确认你的提交（或 rebase 后的新提交）出现在最顶端 - 点开该提交，检查
Files changed页签，确认冲突文件的修改内容与你本地解决的一致 - 如果项目配置了 CI，留意流水线状态 —— 有些平台对 rebase 后的提交不自动触发，需手动点击 “Re-run jobs”
最容易被忽略的是：解决冲突后没 git add 就直接 git commit，导致 Git 生成了一个空合并提交（只记录 parent，没实际变更）。这种提交 push 后看似成功，但远程代码根本没更新，等上线才发现问题。
