1. 这个报错到底在说什么
[rejected] master -> master (fetch first)加上error: failed to push some refs，再跟一句(non-fast-forward)，这套组合拳几乎每个用 Git 做协作开发的人都挨过。我第一次遇到的时候盯着终端愣了半分钟，明明本地提交都成功了，git log看着也正常，怎么一推就翻脸。后来才明白，这不是 Git 在刁难你，而是它在尽职尽责地拦着你干一件危险的事。
先把结论摆出来：这个报错的本质是你本地的分支和远程分支已经分叉了。所谓分叉，就是远程仓库里有一些提交是你本地没有的，而你本地也有一些提交是远程没有的。Git 不知道该怎么把这两条线合并，它不敢擅自替你做决定，于是干脆拒绝推送，让你先自己处理。
这里要理解一个核心概念：快进（fast-forward）。假设远程分支的提交历史是 A→B→C，你本地是基于 C 又提交了 D 和 E，那么推送时远程只需要把指针从 C 直接挪到 E 就行，历史是一条直线，这叫快进推送，Git 很乐意。但如果远程在你不知情的时候已经变成了 A→B→C→F，而你本地是 A→B→C→D→E，两条线从 C 之后就岔开了，Git 就没法简单地挪指针了，这就是 non-fast-forward。
那fetch first是什么意思？这是 Git 给你的建议：先执行git fetch把远程的最新状态拉下来看看，别急着推。它其实是在说"你手里的信息过时了，先去同步一下再决定怎么办"。
这个报错最常出现的场景有这么几个：团队协作时别人先你一步推了代码；你在多台机器上开发同一个分支；你在网页端直接改了文件并提交；或者你之前 rebase 过本地历史导致和远程对不上。搞清楚是哪种场景，解决思路就清晰了一半。
提示：看到这个报错千万别第一反应就上
git push -f。强制推送会覆盖远程别人的提交，在团队协作里这基本等于"删库跑路"级别的操作，除非你百分百确定这个分支只有你一个人在用。
2. 先搞清楚为什么会分叉
2.1 分叉的三种典型成因
要解决问题，得先知道问题从哪来。我把这些年踩过的坑归了归类，分叉基本逃不出下面三种情况。
第一种：队友抢先推送。这是最常见也最正常的。你和 A 同学同时从远程拉了一份代码，你改完提交了，A 同学也改完提交了并且比你先推上去。这时候远程已经往前走了，你本地还停在旧的位置，一推就分叉。这种情况完全不用慌，属于正常协作节奏。
第二种：多端操作不同步。比如你在公司电脑上提交了代码但忘了推，回家用笔记本又拉了一份旧代码继续改，两边各自产生了提交。等你想把笔记本上的成果推上去时，就发现和公司电脑推的那份对不上了。这种分叉本质上是"同一个人的两条时间线"打架。
第三种：历史被改写。你或者别人对已经推送过的提交做了rebase、commit --amend或者reset，导致本地历史和远程历史的"血缘关系"变了。这种情况下 Git 会认为两条线毫无共同祖先可言，处理起来要格外小心，因为强推的风险最大。
2.2 用一张表看懂不同场景的处理策略
| 场景 | 分叉原因 | 推荐处理方式 | 风险等级 |
|---|---|---|---|
| 队友抢先推送 | 远程有新提交 | git pull --rebase后推送 | 低 |
| 多端不同步 | 本地两条线 | 先 fetch 对比，再 merge 或 rebase | 中 |
| 历史被改写 | rebase/amend 过 | 确认分支独占后强推 | 高 |
| 网页端改过文件 | 远程多出提交 | pull 合并后推送 | 低 |
这张表建议存下来，下次遇到报错先对号入座，能省不少瞎折腾的时间。风险等级高的那两行，操作前一定要确认分支是不是只有你在用。
2.3 为什么 Git 不自动帮你合并
很多人会问，既然 Git 这么聪明，为什么不自动帮我 merge 一下再推呢？答案在于自动合并可能产生意料之外的结果。合并意味着要创建一个新的合并提交，或者改写你的提交历史，这两种操作都会改变仓库的状态。Git 的设计哲学是"危险操作必须由人显式确认"，它宁可报错让你停下来，也不愿意悄悄替你做一个你可能不想要的合并。
这个设计其实很贴心。想象一下，如果 Git 自动帮你 merge 了，结果把两个功能分支的代码搅在一起，你还浑然不知地推了上去，那排查起来才是真的灾难。所以这个报错不是障碍，而是一道安全阀。
3. 手把手解决：两种主流方案
3.1 方案一：pull --rebase，保持历史整洁
我个人最推荐的方式是git pull --rebase。它的逻辑是：先把远程的新提交拉下来，然后把你本地的提交"摘"下来，暂时放到一边，等远程的提交就位后，再把你的提交一个一个重新"贴"到最新的历史顶端。最终效果是历史变成一条干净的直线，没有多余的合并提交。
具体操作步骤是这样的：
# 第一步，先看看当前状态，确认本地有哪些提交 git log --oneline -5 # 第二步，拉取远程并变基 git pull --rebase origin master # 第三步，如果变基过程顺利，直接推送 git push origin master如果变基过程中出现冲突，Git 会停下来告诉你哪些文件冲突了。这时候你需要手动打开冲突文件，找到<<<<<<<、=======、>>>>>>>这些标记，决定保留哪部分代码，改完后执行：
git add 冲突的文件名 git rebase --continue如果改到一半发现搞砸了想放弃，随时可以git rebase --abort回到变基前的状态，这个命令相当于"后悔药"，非常实用。
注意：
git pull --rebase会把你的本地提交重新应用到远程最新提交之上，这意味着你本地提交的哈希值会变。如果这些提交已经推送到远程被其他人拉取过，就不要再 rebase 了，否则会给别人制造麻烦。
3.2 方案二：普通 merge，保留完整历史
如果你不介意历史里多几个合并提交，或者团队规范就是要求用 merge，那用普通 pull 也行：
git pull origin master git push origin mastergit pull默认行为是 fetch 加 merge。它会把远程的新提交拉下来，然后创建一个合并提交，把你的本地提交和远程提交"缝合"在一起。好处是操作简单，历史保留了真实的分支合并轨迹；坏处是提交历史会变得比较"乱"，尤其是频繁 pull 的时候，合并提交会堆得满屏都是。
我个人的习惯是：个人分支用 rebase 保持整洁，公共分支用 merge 保留轨迹。这样既照顾了可读性，又不会在主干上留下太多噪音。
3.3 两种方案的对比与选择
| 对比项 | pull --rebase | pull (merge) |
|---|---|---|
| 历史形态 | 一条直线 | 有分叉和合并点 |
| 提交哈希 | 会改变 | 保持不变 |
| 冲突处理 | 逐个提交解决 | 一次性解决 |
| 适用场景 | 个人分支、追求整洁 | 公共分支、多人协作 |
| 学习成本 | 稍高 | 低 |
选哪个没有绝对的对错，关键看团队约定和分支用途。但有一点是共通的：处理完分叉后一定要先本地验证再推送，别解决完冲突闭着眼睛就推。
4. 那些年我踩过的坑
4.1 强推的诱惑与代价
刚工作那会儿，遇到这个报错我图省事，直接git push -f一把梭。有一次推完，A 同学跑过来问我："我昨天推的那个功能怎么没了？"我当时冷汗就下来了。强推把远程分支的指针强行指向了我本地的历史，A 同学的提交因为不在我的历史线上，直接被"抹掉"了。虽然理论上还能通过 reflog 找回来，但那个过程相当折腾。
所以这里立个规矩：强推之前必须确认三件事。第一，这个分支是不是只有你一个人在用；第二，远程有没有你本地没有的提交；第三，你有没有备份或者确认这些提交可以丢弃。三个条件缺一个，都别碰-f。
如果确实需要强推（比如你 rebase 了自己的个人分支），用更安全的--force-with-lease：
git push --force-with-lease origin 你的分支名它比-f多了一层检查：如果远程在你 fetch 之后又有了新提交，它会拒绝推送。这相当于给你加了一道保险，防止误伤别人的提交。
4.2 冲突解决到一半想放弃
rebase 或 merge 到一半，冲突文件一大堆，越改越乱，这时候最想做的就是"我不干了，回到从前"。Git 给了你退路：
- rebase 中途放弃：
git rebase --abort - merge 中途放弃：
git merge --abort
这两个命令会把你带回操作开始前的状态，干干净净。我强烈建议新手在动手前先记下当前分支名和提交哈希，万一 abort 之后还是懵，至少知道自己在哪。
4.3 fetch 了但没看就 merge
git fetch只是把远程的最新状态下载到本地的远程跟踪分支（比如origin/master），它不会改动你的工作区。很多人 fetch 完直接 merge，结果发现合并进来一堆自己没预期的改动。正确的做法是 fetch 之后先对比：
git fetch origin git log HEAD..origin/master --oneline这条命令会列出远程有而本地没有的提交，让你心里有数再决定怎么合并。养成"先看后合"的习惯，能避免很多意外。
4.4 常见问题速查表
| 报错或现象 | 可能原因 | 解决命令 |
|---|---|---|
| non-fast-forward | 远程有新提交 | git pull --rebase |
| 冲突标记满天飞 | 同一文件被双方修改 | 手动解决后git add |
| rebase 卡住不动 | 有未解决的冲突 | 解决后git rebase --continue |
| 想撤销 rebase | 操作失误 | git rebase --abort |
| 强推后丢了提交 | 覆盖了远程历史 | git reflog找回 |
这张表我建议贴在显示器边上，遇到问题先扫一眼，比临时搜索快得多。
5. 从根源上减少这类报错
5.1 养成先拉后推的习惯
最简单的预防手段就是每次推送前先拉一次。听起来很笨，但真的管用。我现在的工作流基本固定成：写代码 → 提交 →git pull --rebase→ 解决冲突（如果有）→git push。这套流程走下来，non-fast-forward 报错基本绝迹。
有人会问，那如果我 pull 的时候正好没冲突，是不是就白拉了一次？不会的，pull 本身很快，而且能确保你推的是最新基础上的提交，这个时间花得值。
5.2 小步提交，频繁推送
另一个血泪教训是：别攒一大堆改动再一次性推。我曾经一个功能写了三天，攒了二十多个提交，结果推送时和远程冲突得一塌糊涂，解决冲突花的时间比写代码还长。后来改成每完成一个小功能点就提交推送，冲突范围小，解决起来也快。
频繁推送还有个好处是，你的工作进度实时同步到了远程，万一本地机器出问题，代码也不会丢。这比任何本地备份都靠谱。
5.3 分支策略上的考量
如果团队人多，建议约定好分支使用规范。比如主干分支只接受合并请求，个人开发都在自己的特性分支上进行。这样每个人推的都是自己的分支，天然避免了和别人的直接冲突。等特性开发完，再通过合并请求的方式并入主干，冲突在合并请求阶段解决，不影响其他人的推送。
特性分支的命名也有讲究，我一般用feature/功能名或者fix/问题描述这种格式，一眼就能看出这个分支是干嘛的。别用test、temp、aaa这种名字，过两天自己都不记得是啥了。
5.4 配置默认的 pull 行为
Git 2.27 之后可以用配置项指定 pull 的默认策略，省得每次都要敲--rebase：
# 设置 pull 默认使用 rebase git config --global pull.rebase true # 或者设置成只在快进时合并，否则报错提醒 git config --global pull.ff onlypull.ff only这个配置挺有意思，它要求 pull 必须是快进合并，一旦需要真正的合并就报错，逼着你显式决定怎么处理。适合那些希望对自己历史有完全掌控的人。
6. 几个容易被忽略的细节
6.1 远程跟踪分支的更新时机
很多人搞不清origin/master这个远程跟踪分支什么时候更新。它只在git fetch或git pull的时候更新，你本地提交、切换分支都不会动它。所以有时候你git log origin/master看到的是旧信息，别慌，先 fetch 一下再看。
理解这一点很重要，因为git status里显示的"你的分支领先 origin/master 几个提交"这类信息，都是基于上次 fetch 时的快照。如果远程在你上次 fetch 之后又变了，这个信息就是过时的。
6.2 HEAD 分离状态下的推送
有时候你会处于"分离头指针"（detached HEAD）状态，比如 checkout 到某个具体的提交哈希上。这时候提交的代码不属于任何分支，推送时会遇到各种奇怪的问题。解决办法是先基于当前状态创建一个新分支：
git checkout -b 新分支名然后再推送这个新分支。别在分离头指针状态下硬推，容易把自己绕晕。
6.3 大文件导致的推送失败
还有一种情况容易被误认为是 non-fast-forward，其实是推送超时或文件过大。如果报错信息里出现pack exceeds maximum allowed size或者类似的字样，那问题不在分叉，而在文件体积。这时候需要检查是不是误提交了大文件，用git rm --cached移除后重新提交。
判断方法很简单：看报错的关键词。non-fast-forward 一定会有[rejected]和(fetch first)或(non-fast-forward)的字样，没有这些关键词的推送失败，八成是别的原因。
6.4 网络中断后的重试
推送过程中网络断了，重新推的时候有时也会报 non-fast-forward。这是因为远程可能已经接收了部分数据。这种情况先 fetch 看看远程状态，如果远程确实有了你的提交，那就不用再推了；如果没有，按正常流程 pull 再 push 即可。
7. 一套可复用的标准处理流程
把上面这些经验串起来，我整理了一套遇到这个报错时的标准动作，照着走基本不会出错：
- 冷静，别强推。先执行
git status和git log --oneline -5看清本地状态。 - 拉取远程最新。
git fetch origin，然后git log HEAD..origin/master --oneline看看远程多了什么。 - 选择合并策略。个人分支用
git rebase origin/master，公共分支用git merge origin/master。 - 解决冲突。有冲突就手动改，改完
git add，rebase 的话继续git rebase --continue。 - 本地验证。跑一下测试，确认代码没问题。
- 推送。
git push origin 你的分支名。 - 万一搞砸。rebase 用
--abort，merge 用--abort，强推过的用git reflog找回。
这套流程我用了好几年，从最初的每次报错都手忙脚乱，到现在基本能条件反射地处理。核心就一句话：先同步，再合并，最后推送，永远别用强推走捷径。
最后分享一个小技巧：如果你经常在同一个仓库上遇到这个问题，可以在仓库根目录建一个简单的 shell 脚本，把"fetch + rebase + push"打包成一条命令，每次推送前跑一下。省事的同时也强制自己走了正确的流程。工具是死的，习惯是活的，把正确的操作变成肌肉记忆，这类报错自然就离你远去了。
排序算法原理与工程选型指南)
