1. 这个报错到底在闹什么脾气但凡用 Git 管过代码的人几乎都撞上过这个场景本地改了一堆文件信心满满敲下git push结果终端甩回来一行红字大意是“更新被拒绝因为远程包含你本地没有的提交”。紧接着你想着先git pull拉一下结果又冒出来一句“你的本地修改会被覆盖”或者干脆进入一个莫名其妙的合并状态编辑器弹出来让你写合并信息。整个过程像极了你想进一扇门门里有人往外推你往里推两边卡在门框上谁也动不了。这篇随笔聊的就是这个卡门的问题核心手段是两个命令的组合拳git stash和git pull --rebase。前者负责把你手头没提交完的活儿先“收进抽屉”后者负责把你的本地提交“重新排队”到远程最新提交之后。两个动作配合起来能干净利落地解决“本地与目标分支不一致导致提交失败”这个高频痛点。适合谁看如果你已经会用git add、git commit、git push这三板斧但一遇到冲突、一看到 rebase 就心里发毛那这篇就是写给你的。如果你连分支概念都还模糊也没关系我会把每个动作背后的意图掰开揉碎讲清楚你照着做也能跑通。整篇内容围绕一个真实开发中反复出现的场景展开多人协作同一个分支你本地有未提交改动远程又有了新提交push 被拒怎么用最稳的方式把代码送上去同时不弄丢自己的活儿也不把别人的提交搅乱。我先把结论摆在前头这个问题的本质不是 Git 在刁难你而是它在保护两样东西——你本地未提交的改动以及远程分支的提交历史。理解了这个“保护”逻辑后面所有命令的选择就都有了依据。2. 先把冲突的来龙去脉理清楚2.1 为什么 push 会被拒绝Git 的远程分支有一个“快进”规则。简单说你推送的提交必须是远程分支当前状态的直接延续也就是远程分支的 HEAD 必须是你新提交的祖先。打个生活化的比方远程分支像一列已经开出去的车你的本地提交是新车厢Git 要求你把新车厢挂在当前最后一节车厢后面。但如果你本地这列车是从一个旧站点出发的中间远程已经加挂了好几节车厢你直接把自己的车厢挂上去就会和已有的车厢位置打架Git 干脆拒绝让你先同步。这个拒绝信息里通常会出现non-fast-forward或者fetch first字样。很多人第一反应是加--force强推这是最危险的操作因为它会把远程上别人的提交直接抹掉。我在早期项目里见过一次强推事故某位同学为了省事push -f结果把另一位同事当天上午的三个提交全部冲掉靠备份才捞回来。所以看到 push 被拒第一反应应该是“我落后了先同步”而不是“我要强推”。2.2 本地未提交改动为什么成了拦路虎当你执行git pull时Git 会先 fetch 远程更新然后尝试合并或变基到你的本地分支。问题在于如果你工作区里有未提交的修改而这些修改涉及的文件恰好也被远程更新改动了Git 就没法安全地完成合并于是抛出“local changes would be overwritten”的警告并中止。这里有个容易被忽略的细节即使你未提交的文件和远程改动的文件不是同一个某些情况下 pull 依然可能因为索引状态不干净而受阻。所以最稳妥的做法不是赌“应该不冲突”而是主动把手头的改动先安置好。这就是git stash出场的地方。2.3 stash 和 pull --rebase 各自扮演什么角色git stash的作用是把工作区和暂存区的改动“打包暂存”让工作区回到干净状态相当于你把桌上摊开的图纸先卷起来放进柜子桌面清空了好办事。git pull --rebase则是先拉取远程最新提交然后把你本地尚未推送的提交“摘下来”重新一个个接到远程最新提交的后面形成一条线性历史。两者组合的逻辑链条是stash 清空工作区 → pull --rebase 同步远程并重排本地提交 → stash pop 把抽屉里的改动取回来。整个过程你的代码不丢远程历史不被污染本地提交也保持线性整洁。相比直接git pull默认 merge产生一个多余的合并提交rebase 方式在多人协作的分支上更受欢迎因为它让提交历史像一条直线回溯问题时清爽得多。3. 完整操作流程一步步走3.1 第一步确认当前状态别急着动手动手之前先看清楚自己在哪。执行git status重点看三件事当前在哪个分支、有哪些已修改未暂存的文件、有哪些已暂存未提交的文件。再执行git log --oneline -5看看本地最近几个提交心里有数哪些是还没推上去的。我习惯再加一条git fetch origin先把远程信息拉下来注意 fetch 只更新远程跟踪分支不动你的工作区然后git log --oneline HEAD..origin/你的分支名看看远程比你多了哪些提交。这一步的意义在于预判冲突范围如果远程新增的提交改的文件和你手头改的文件完全不搭界那后面基本一路顺风如果撞上了你提前有个心理准备。3.2 第二步stash 收好手头的活儿执行git stash push -m 描述这次改动。加-m是个好习惯相当于给抽屉贴个标签后面git stash list时能一眼认出哪次是哪次。如果你只想暂存部分文件可以写成git stash push -m 说明 文件路径1 文件路径2。如果连未跟踪的新文件也想一起收进去加-u参数。执行完再git status确认工作区干净了。这里有个坑要提醒stash 默认不包含未跟踪文件如果你新建了文件却没加-u它还会留在工作区pull 时依然可能碍事。所以养成习惯stash 之后一定用git status复核一遍看到“nothing to commit, working tree clean”才算真正清场。3.3 第三步pull --rebase 同步并重排执行git pull --rebase origin 你的分支名。这条命令内部做了两件事fetch 远程最新然后把你本地领先的提交 rebase 到远程最新之上。执行过程中如果本地提交和远程提交改了同一处代码会停下来让你解决冲突。解决冲突的流程是编辑冲突文件删掉、、这些标记保留正确内容然后git add 冲突文件接着git rebase --continue。如果中途发现搞错了想退出git rebase --abort可以回到 rebase 之前的状态这是你的安全绳记住它。注意rebase 过程中千万不要执行git commit去“提交冲突解决结果”那会把 rebase 流程搞乱。正确动作永远是git add之后git rebase --continue。3.4 第四步stash pop 取回改动rebase 完成后执行git stash pop。如果之前 stash 了多次用git stash list查看编号然后git stash pop stash{编号}指定取哪一次。pop 和 apply 的区别在于pop 取回后会从 stash 列表里删掉这条记录apply 则保留。一般用 pop 就行干净。取回时如果和 rebase 后的代码有冲突Git 会提示冲突文件处理方式和普通冲突一样改完git add即可不需要再 commit因为 stash pop 的改动本来就在工作区。处理完确认git status然后正常git add、git commit、git push这次推送就能顺利通过。3.5 参数选择背后的计算逻辑有人会问为什么不直接git pull加--no-rebase这就涉及历史形态的取舍。假设远程有提交 A、B你本地基于旧提交 O 有提交 C、D。merge 方式会产生一个新提交 M历史变成 O→A→B→M而 C、D 挂在 M 的另一条父线上形成分叉再汇合。rebase 方式则把 C、D 重写成 C、D历史变成 O→A→B→C→D一条直线。在团队规范要求线性历史、或者用某些自动化工具做变更追溯时直线历史明显更好读。代价是 rebase 会改写你本地提交的哈希值所以有一条铁律只对尚未推送的本地提交做 rebase已经推送到共享分支的提交不要 rebase否则会给协作者制造麻烦。这条边界必须刻在脑子里。4. 踩过的坑和排查速查表4.1 那些年 stash 丢过的改动最常见的翻车是 stash pop 冲突后手忙脚乱误操作把改动弄丢。其实 stash 的记录在没被 drop 之前都还在即使 pop 冲突了记录也不会自动删除。真丢了可以用git fsck --lost-found找 dangling commit或者git stash list确认是否还在。我个人的习惯是重要改动 stash 之前先git diff backup.patch存一份补丁文件双保险成本极低。另一个坑是 stash 了太多条忘了清理时间一长自己都分不清哪条是哪条。建议每次 stash 都带-m说明并且定期git stash list清理已经没用的记录用git stash drop stash{编号}删掉。4.2 rebase 冲突反复出现的处理思路有时候 rebase 会在多个提交上反复让你解决同一处冲突很烦。这通常是因为你本地多个提交都改了同一块区域。处理办法是耐心逐个--continue或者提前用git rebase -i把本地提交 squash 合并成一个再 rebase冲突只需解决一次。交互式 rebase 里把pick改成squash就能合并提交这个技巧在提交历史比较碎的时候特别好用。4.3 常见问题速查表现象可能原因处理动作push 提示 non-fast-forward远程有新提交本地落后先 fetch再 pull --rebasepull 提示 local changes overwritten工作区有未提交改动先 stash再 pullrebase 卡住不动有冲突未解决改文件后 git add再 --continuestash pop 报冲突取回的改动与当前代码冲突手动解决后 git add想放弃 rebase操作失误git rebase --abortstash 记录找不到误 dropgit fsck --lost-found 尝试找回4.4 一个容易被忽视的配置项git config --global pull.rebase true可以把 pull 的默认行为设为 rebase省得每次手动加参数。但我不建议新手一上来就全局设置因为一旦默认 rebase遇到冲突时的处理门槛比 merge 高。建议先在具体项目里用git config pull.rebase true局部开启等对 rebase 流程熟悉了再考虑全局。另外git config --global rebase.autoStash true可以让 rebase 前自动 stash、结束后自动 pop省掉手动两步但这个自动行为在冲突复杂时反而让人看不清状态我个人的做法是手动控制图个心里有数。5. 把流程固化成肌肉记忆这套组合拳用多了之后其实可以浓缩成一个条件反射push 被拒 → 看 status → 有未提交改动就 stash → pull --rebase → 解决冲突 → stash pop → 再 push。整个链条里最关键的不是命令本身而是那个“先看状态再动手”的习惯。我见过太多人一遇报错就凭感觉敲命令结果在 rebase 中途又去 commit把状态搅成一团最后只能 abort 重来。还有一个心得值得分享在 rebase 之前如果本地提交比较多且历史比较乱先花两分钟用git log --oneline理一遍必要时 squash 整理再执行 rebase冲突处理的体验会好很多。这就像出门前先把背包整理好路上才不会手忙脚乱。至于 stash 的说明信息别嫌麻烦写清楚“改了登录校验的边界判断”比写“临时”有用一百倍一周后回来你还能看懂自己当时在干什么。最后提一个扩展方向如果你的团队对提交历史要求严格可以把这套流程和提交信息规范结合起来rebase 保证线性规范化的 commit message 保证可读两者叠加代码库的历史追溯体验会提升一个档次。这个组合我在几个协作项目里都推行过初期大家觉得多两步麻烦用顺了之后回看历史清爽没人愿意再回到满屏 merge commit 的状态。