遇到 failed to push some refs 时，先别急着改 remote 配置，也不用反复重试推送。这个提示本身只说明远程服务器拒绝接受你的提交，具体原因需要按顺序排查。下面这份处理记录，按“先判断局部问题还是远程限制，再把远程提交合入本地，最后重新推送”的顺序来写。

先看远程分支比本地多出了哪些提交

当git push被拒绝并提示failed to push some refs时，最常见的原因是远程分支包含本地分支没有的提交，而你的本地修改不是基于最新远程状态。此时先执行git fetch，再运行git log HEAD..origin/分支名查看本地落后了哪些提交。如果日志不为空，说明远程有更新，你的推送会被视为非快进推送而被拒。另一种判断是检查远程分支保护规则，若推送被拒且提示“protected branch”或hook拒绝，则可能是没有权限或违反团队规范。

这里要区分两种场景：如果 git log HEAD..origin/分支名 有输出，说明远程确实有新提交，本地分支落后了。如果这个输出为空，但推送仍被拒，问题就不在提交差异，而在于远程分支保护、权限或 hook 校验。注意，这个命令的起点是本地 HEAD，终点是远程分支，顺序别写反。写反了看到的就是本地比远程多出的提交，会被误判为没有落后。

把远程提交合进本地：优先用 rebase 而不是 merge

在安全的场景下，优先使用git pull --rebase将远程提交变基到本地提交之前，而不是直接使用git pull。执行完rebase后，用git status确认没有冲突，再重新推送。如果rebase过程出现冲突，需要手动编辑文件解决，然后git add对应文件，继续git rebase --continue。这种方式能保证提交历史线性，避免产生多余的合并节点。若远程分支已有大量改动且你只想保留本地修改，可以谨慎使用git push --force-with-lease，但必须确保这条分支只有你一个人在协作，否则会覆盖他人提交。

rebase 适合的场景是：本地只有少量未推送提交，远程有若干新提交，且你不想在历史里留下一个“merge origin/分支”节点。执行前可以先 git fetch，再用 git log --oneline HEAD..origin/分支名 确认远程提交确实是你需要的。如果远程改动量很大，或者本地提交很多，rebase 可能产生连续冲突。这时建议一项一项处理，不要一股脑解决到最后。每解决完一组冲突就 git add 再继续，直到 rebase 完成。

如果你所在团队约定必须使用 merge 而不是 rebase，那么 git pull --no-rebase 会生成一个合并提交。这个操作本身没有错，只是会让历史出现分叉。遇到这种情况，优先遵守团队约定，不要为了“历史好看”而去改写别人提交。

强制推送的边界：只能用在私有分支

不要对共享分支执行git push --force或git push --force-with-lease。强制推送会改写远程历史，可能导致其他协作者本地提交丢失。即使你用了--force-with-lease，如果本地对远程状态的缓存过期了，仍然存在覆盖他人最新提交的风险。更安全的做法是只对个人私有分支使用强制推送。另外，在rebase过程中不要中断和随意终止，如果放弃rebase，使用git rebase --abort会回到rebase前的状态，但已经手动修改过的文件不会自动恢复，需要谨慎处理。

如果你已经决定在私有分支上强制推送，建议先运行 git fetch 把远程状态刷新到最新，再执行 git push --force-with-lease。这个选项会检查你本地缓存的远端哈希是否与远程一致，不一致就拒绝推送。注意“一致”不代表安全，因为远程可能在你 fetch 之后又有了新提交，但你的缓存里没有。所以更稳妥的办法是：先 git ls-remote origin 分支名 拿到当前哈希，确认它就是你上次基于的那个提交，再强制推送。

推送前核对远程地址、上游分支和引用状态

很多被拒问题其实出在推送目标上。先用 git remote -v 确认远程地址是对的，避免把代码推到旧仓库。再用 git branch -vv 看本地分支有没有设置上游。如果没有显示 [origin/分支名]，推送时要用 git push -u origin 分支名 建立跟踪关系。接下来，运行 git ls-remote origin 分支名 获取远程分支的当前哈希，用 git rev-parse HEAD 对比本地。如果两边不一致，先按前面的方法处理，而不是继续强制推送。

还有一种常见情况：远程分支被删除后重新创建，本地缓存的 remote-tracking 分支没有更新。这时推送可能会提示 remote ref 不存在或错误的状态。处理方式是用 git fetch --prune 清理无效引用，然后重新设置上游。这个命令不会影响本地提交，可以放心执行。

推送成功后，用这些信号确认结果

重新执行 git push 后，如果命令返回成功，先看 git status。正常会显示 “Your branch is up to date with 'origin/分支名'” 或类似状态，说明本地和远程已经同步。如果你之前 rebase 过，提交哈希会变化，这是正常的。但要核对提交内容有没有丢失：使用 git log --stat 检查最近几次提交涉及的文件列表，或运行 git log origin/分支名..HEAD 看本地相对远程是否还有差异。

也建议在推送后尽快执行一次 git fetch，然后比较 git log origin/分支名 和本地分支的哈希。如果远程托管平台有网页界面，可以打开提交历史页面，看最新提交是否包含你刚才推上去的内容。网络缓存有时会延迟，稍等再刷新。

经常遇到这个提示，先想想协作方式

如果这个提示反复出现，说明你经常在过期的分支上开发。比较好的习惯是：每次开始新任务前先 git pull --rebase 更新一次，开发过程中不要长时间停留在一个旧基线；提交前再次 fetch 并查看是否有新提交，有就 rebase 后再推。多人共享的分支不要随意强推，也不要依赖 rebase 来解决所有冲突。短生命周期分支和频繁同步，比攒了一大堆提交后再处理要省心得多。