Necromanov做过开发的人应该都有过这种经历：本地代码正改到一半，远程仓库那边同事已经推了新提交上来。你想拉取远程更新，可低头一看，工作区还有一堆没提交的修改。直接 git pull？怕冲突，怕覆盖，怕辛苦半天的代码直接没了。不拉吧，分支落后太多，后面合并起来更痛苦。
我的习惯是：先冷静几秒钟，想清楚本地修改到底处于什么状态，再按状态选择对应的安全拉取方案。这篇文章就把这套思路和实操方法完整梳理出来，涉及 stash、fetch、merge、rebase、冲突解决等核心操作，适合所有用过 Git 但还没形成安全操作习惯的开发者。全文以我实际踩过的坑为基础，看完你就能总结出属于自己的"本地有修改时安全拉取远程"流程。
1. 先搞明白：你的本地修改属于哪种状态
很多人一慌就上手操作，恰恰是乱操作的根源。Git 里的"本地修改"其实分好几种类型，每种类型的安全处理方式完全不同。先把状态诊断清楚，后面的事情就顺了。
1.1 未跟踪文件、已跟踪修改、已提交未推送
第一类是未跟踪文件（untracked）。这类文件从来没有被 git add 过，Git 把它当作一个完全陌生的新文件，比如你新建的 notes.txt、配置文件模板、临时脚本等等。这类文件的特点是不在 Git 版本控制的索引里，普通模式下许多 Git 操作根本不会碰它们。
第二类是已跟踪文件的修改，还可以进一步细分为未暂存修改（unstaged）和已暂存修改（staged）。未暂存的意思是文件在版本控制里存在，但你改完之后还没执行 git add；已暂存则是你已经执行了 git add，修改被放进了暂存区，只差一次 git commit。这两者的区别直接影响 stash 和冲突恢复的行为。
第三类是已提交未推送的提交（committed but not pushed）。你在本地执行过 git commit，但还没执行 git push。这时代码已经形成了 Git 历史上的新节点，本地分支和远程分支就出现了分叉，处理方式和上面两类完全不同。
1.2 混合状态才是最常见的现实
实际情况里，这三种状态常常叠加出现。比如你正在开发一个新功能，新增了两个文件，改了一个旧文件，中途顺手 commit 了一次，然后又继续改代码。这时候你的本地就同时存在未跟踪文件、未暂存修改、已提交未推送的提交。
这种混合状态让很多新手无比头疼，因为"提交"过的部分和"没提交"的部分需要的恢复手段不同。记住一个简单判断逻辑：凡是没 commit 的内容，本质都是"还没被 Git 保护"的内容；凡是 commit 过但没 push 的内容，本质是"本地独有但已经受保护"的内容。安全拉取的核心就是分别处理好这两类内容，让远程更新能顺利归位，同时又不损失你本地的一丁点劳动成果。
值得强调的是，诊断状态不需要凭感觉，一条命令就能看清：
bash复制git status
这条命令会分区块展示未暂存修改、已暂存修改和未跟踪文件。配合 git log 查看本地提交情况，你的"本地修改画像"就完整了。我建议执行任何拉取操作之前，都先跑一遍 git status，这就像开车前看后视镜，几秒钟的事，能避免绝大多数事故。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心原则：把"安全拉取"拆成"备份、拉取、恢复"三步
很多人的误区是直接执行 git pull，认为这就是"拉取远程更新"的全部。事实上，git pull 在底层执行的是两个动作的合并：git fetch 加 git merge（或 rebase）。fetch 负责把远程更新下载到本地的远程跟踪分支，merge 或者 rebase 负责把远程内容合并进你的工作分支。
2.1 为什么直接 pull 是危险的
直接 git pull 的危险在于，你没法控制第二步的合并过程。如果本地有未提交的修改，而远程更新碰巧改了同一个文件的同一区域，Git 会拒绝合并并报错。如果本地有已提交未推送的提交，git pull 默认会走 merge 路线，产生一个合并提交，把两个分支的历史搅在一起。
更麻烦的情况是，如果你不小心把 git pull 写成了 git pull --rebase，而本地又有未提交的修改，某些旧版本的 Git 会直接拒绝执行。现在的一些 Git 版本支持 rebase.autoStash 配置，会自动把未提交的修改 stash 起来，但很多老项目或者没配置过的电脑上，这个行为并不存在。
2.2 安全流程的三步模型
我给自己定下的安全拉取流程，永远遵守三步模型：
- 备份：先把本地未提交的修改安全地保存起来，常用工具是
git stash，也可以临时创建一个备份分支。 - 拉取：执行
git fetch查看远程更新情况，再执行 merge 或 rebase 把远程内容合到本地分支上。 - 恢复：把第一步备份的本地修改重新应用回工作区，恢复开发现场。
这套流程看起来额外多敲了两三行命令，实际上每一条命令都有明确目的，任何一个节点出问题都能定位修复，不至于让 Git 进入无法挽回的状态。从风险控制角度看，拉起的代码合坏了可以重来，但本地没提交的修改丢了就很难找回，所以备份永远优先。
额外的安全网是，在执行任何 git 操作前，给自己留一个"后悔药"分支：
bash复制git branch backup/pre-pull-20240612
这条命令会基于当前提交创建一个分支，但不切换过去。即使后面的操作失误，你仍然可以跳到这个分支找回原来的代码。成本几乎为零，价值却非常高。我建议在重要项目上养成这个习惯，尤其当你的本地修改比较有价值时。
3. 场景化实操：不同修改状态对应的安全拉取方案
讲完原则，直接给场景化的命令方案。我按四种典型状态分别整理，你可以直接对着自己的 git status 结果选一套用。
3.1 场景一：只有未提交的修改，且已跟踪文件有改动
这是最常见的场景：本地改了文件，还没 commit，远程更新来了。安全方案是 stash 存储修改，拉取更新，再恢复修改：
bash复制git stash push -m "拉取前备份"
git pull --rebase
git stash pop
git stash push 会把当前所有已跟踪文件的修改收进 stash 栈中，工作区恢复到 HEAD 状态。git pull --rebase 用 rebase 方式把远程提交放在本地提交之上，历史线性整洁，适合团队成员较少、对历史整洁度有要求的仓库。最后 git stash pop 把之前的修改重新写回工作区。
这里有几个容易踩的坑。第一，git stash 默认不包含未跟踪文件，也就是你新建的那些文件仍然留在工作区，如果远程更新创建了同名文件，就会报"untracked working tree files would be overwritten"。第二，git stash pop 恢复时，如果本地代码和远程更新都改了同一处内容，会产生冲突，表现为 CONFLICT (content) 提示，这时候需要手动解决，解决完还要用 git stash drop 确认 stash 记录清理掉。
提示：如果你的
git stash pop出现冲突，先别急着删 stash。等冲突解决完、验证无误后再执行git stash drop删除备份。安全第一。
3.2 场景二：有未跟踪的新文件
未跟踪文件在 stash 默认模式下不会被备份，所以在拉取前需要额外处理。你可以在 stash 时带上 -u 参数（或 --include-untracked）把未跟踪文件一并收进 stash：
bash复制git stash push -u -m "包含新文件的备份"
git pull --rebase
git stash pop
需要注意的是，-u 参数会把所有未被忽略的未跟踪文件都收进 stash，包括你可能根本不想移动的日志文件、临时文件。所以 stash 之前用 git status 确认一下未跟踪文件清单，别把不该动的文件卷进来。
另一种做法是手动把未跟踪文件移到备份目录。比如你的新文件在 feature/ 文件夹下：
bash复制mkdir -p /tmp/git-backup
cp -r feature /tmp/git-backup/
这个方法的优势是直观、可控，缺点是你得记得拉取后把文件复制回来。两条路线我都试过：对少量重要新文件，手动复制更保险；对大量未跟踪文件，-u 参数更省事。
3.3 场景三：有已提交未推送的提交
当你本地有若干 commit 但还没 push，远程又更新了，核心问题是两个分支的历史出现了分叉。这个场景我不推荐 stash，因为 commit 已经安全落在 Git 历史中了，真正需要做的是把远程更新合入本地分支。
两条路线任选：
bash复制# 路线 A：merge 方式，保留分叉历史
git fetch origin
git merge origin/你的分支名
# 路线 B：rebase 方式，历史线性
git fetch origin
git rebase origin/你的分支名
路线 A 会生成一个 merge commit，历史中出现一个交汇点，适合多人协作、需要保留真实合并时间的场景。路线 B 会把你的本地提交"移到"远程更新之后，相当于在最新的远程代码之上重放你的提交，历史看起来像一条直线。缺点是一旦出现冲突，需要逐个提交地解决，比较繁琐。
如果你对 rebase 不熟，但想要整洁历史，有个折中方案：先用 merge 解决冲突拉取成功，再考虑是否后续用 rebase 整理。我第一次用 rebase 处理冲突时，连续解决了三个提交的冲突，确实比 merge 累，但整理完的历史十分清爽。没有哪个选择绝对正确，关键是团队约定一致、领导者能解释清楚规则。
3.4 场景四：多种修改状态混合存在
混合状态用统一的一套流程就能解决：
bash复制git status
git stash push -u -m "全量备份：未提交修改+未跟踪文件"
git fetch origin
git rebase origin/你的分支名
git stash pop
如果 rebase 过程中遇到冲突并中断，先解决冲突、git add、git rebase --continue，全部解决完再执行 git stash pop。这套流程覆盖了"未提交修改+未跟踪文件+本地独有提交"三合一的情况，是我处理日常协作的主力方案。
有个细节要提醒：因为 git stash pop 默认从最近的 stash 记录恢复，如果同一时间点存在多个 stash 记录，建议用 git stash list 确认恢复的是哪一条。操作前我在便签上记下 stash 名称的习惯，帮助我避免过劳状态下的操作失误。
4. stash 的正确打开方式：细节决定成败
git stash 是本地有修改时安全拉取远程的核心武器，但很多人只会用最基础的 git stash 和 git stash pop，遇到问题就慌了。这一节展开讲讲 stash 的细节。
4.1 保存、查看、恢复的完整命令集
进阶用法首先是 git stash push。与旧版 git stash save 不同，push 支持更细的控制参数：
bash复制# 只 stash 某一个文件
git stash push -m "只备份配置文件" -- src/config.js
# stash 已暂存和未暂存的全部修改
git stash push -m "全量备份"
# 包含未跟踪文件
git stash push -u -m "备份含新文件"
查看 stash 列表用 git stash list，每一条记录有独立的编号如 stash@{0}。恢复时既可以用 git stash pop（恢复并删除记录），也可以用 git stash apply（恢复但保留记录）。两者的区别很关键：pop 恢复后 stash 记录会消失，如果恢复后发现问题想反悔，无法从 stash 重新拿回来；apply 恢复后记录还在，你可以在恢复后重新 stash 或者确认无误后手动 git stash drop 清理。
我给新手的建议是，第一次恢复修改时优先用 apply，确认代码没问题并运行自测后再 drop。多一步操作，但给了自己一条退路。特别是恢复后立刻出现冲突的场景，保留 stash 记录可以让你随时回到拉取前的干净状态。
注意：执行
git stash pop或apply后如果产生冲突，stash 记录不会自动删除。这意味着你可以反复用git stash show查看原本的改动内容，方便对比合并结果是否正确。
4.2 stash 冲突的产生与处理
stash 恢复产生冲突的根本原因是：你 stash 时的代码基准和当前工作区的基准不一样了。拉取远程更新后，工作区的文件内容已经变化，恢复 stash 里的修改时，如果远程更新恰好也改了同一处，Git 无法自动决定保留谁的代码，于是报冲突。
处理方式：
- 打开冲突文件，搜索
<<<<<<<、=======、>>>>>>>标记。 - 阅读冲突区域的两种内容，手动选择保留哪一侧，或者两者都保留。
- 删除冲突标记符号。
- 保存文件，执行
git add 文件名。 - 全部解决后，确认没有残留冲突标记，执行
git stash drop清理记录。
这个过程本质上是人工完成 Git 无法自动完成的合并决策，要求你对冲突区域的上下文有一定理解。我的经验是：如果你刚提交的改动是为修复某个 bug 写的，远程更新也改了这个区域，那你得先看看远程的改法是否已经修复了 bug，避免盲目保留自己的代码造成逻辑错乱。
4.3 stash 的一些容易被忽略的行为
git stash 不会存储 .gitignore 中忽略的文件。你在项目里生成了一堆编译产物、日志文件，这些文件以 ignore 规则存在，stash 对它们毫无影响，也会在恢复时原样保留。这是好消息，毕竟你不想 stash 一下把日志文件也带走。
另一个行为是 stash 对文件权限、软链接的处理在不同系统上略有差异，特别是 Windows 和 Linux 混合环境。碰到过 git stash 之后脚本失去执行权限的情况，原因是文件模式变更被 stash 记录了，恢复时权限没有兜底。团队成员习惯统一系统环境，遇到跨平台问题时优先检查 filemode 相关配置。
还有一点，如果你有多个 stash 记录，git stash pop 默认弹出 stash@{0}，而不是"最近修改的"。确认要恢复哪个记录，用 git stash list 查看最保险，不用相信记忆。
5. 冲突解决实战：真的撞上了怎么全身而退
不管前期准备做得多好，rebase 或 merge 时依然可能撞上冲突。冲突不可怕，可怕的是不知道怎么定位、怎么解决、怎么验证。这一节分享我实际处理冲突的完整思路。
5.1 冲突的定位与现场诊断
当你执行 git pull --rebase 或 git merge 时，Git 会尝试自动合并。自动合并成功的文件，肉眼看不到任何痕迹；自动合并失败的文件，Git 会在工作区里留下冲突标记，并在终端提示类似：
text复制CONFLICT (content): Merge conflict in src/App.js
Auto-merging src/utils.js
CONFLICT (modify/delete): src/old.js deleted in HEAD and modified in feature
诊断命令是 git status，冲突文件会出现在 "Unmerged paths" 区域。你也可以用 git diff --name-only --diff-filter=U 快速列出所有冲突文件。拿到清单后，逐个打开文件搜索冲突标记。
冲突标记的结构：
text复制<<<<<<< HEAD
你的本地代码
=======
远程更新的代码
>>>>>>> origin/分支名
标记的语义是：<<<<<<< 到 ======= 之间是当前分支（HEAD 或本地提交）的内容，======= 到 >>>>>>> 之间是另一侧的内容。手动编辑时把不需要的部分连带着标记符号一起删掉，保留需要的部分，一个冲突就算处理完了。
5.2 解决冲突的完整实操步骤
我处理一个文件的冲突通常按这个顺序走：
-
先用
git show查看冲突区域两个版本的上下文。比如git show HEAD:src/App.js看本地版本，git show origin/你的分支名:src/App.js看远程版本。看上下文比看冲突标记本身更有效，能理解对方为什么这么改。 -
编辑文件，决定保留内容。如果双方改动的是不同逻辑，通常可以都保留，代码顺序按合理逻辑排列；如果双方改动的是同一行且目的互斥，需要判断哪个更符合当前需求。
-
删干净所有冲突标记，保存文件。
-
执行
git add 文件名，把解决结果标记为已暂存。 -
如果是 rebase 流程，接着执行
git rebase --continue；如果是 merge 流程，直接git commit完成合并提交。 -
全部冲突解决后，执行一次全局搜索，确认没有残留的
<<<<<<<标记。用 IDE 的全局搜索或者命令行都行。
bash复制grep -r "<<<<<<<" src/
这个步骤我每次都做，因为手滑删漏一个标记的教训太过深刻。残留的冲突标记会被当成普通文本提交进仓库，轻则污染代码，重则影响构建。
5.3 冲突之后的验证工作
冲突解决完不代表事情结束了。合并后的代码要能通过构建和测试才算真正安全。建议按顺序执行：
bash复制# 编译或构建
npm run build # 前端项目示例
# 跑测试
npm test
# 或者至少做一次语法检查
npm run lint
我踩过一次不验证就交付的坑：某次合并冲突时，远程删除了一个函数，我本地代码里还在调用它，IShell 让我感觉构建没问题的关键步骤完全缺失，后来 CI 构建直接失败，回滚才恢复正常。从此我把"验证"当作合并流程的最后一步，不接受任何例外。
如果你在解决冲突时拿不准某段代码的意图，最好的方式是找到远程提交的作者，直接询问改动背景。这比盯着冲突标记猜半天高效得多，也避免了修复冲突时引入新 bug。
6. 常见问题速查与避坑记录
把日常协作中高频出现的问题和解决方案整理成一张速查表，团队新人可以直接照着操作。
6.1 高频问题速查表
| 问题 | 典型场景 | 解决方案 |
|---|---|---|
| stash pop 报 CONFLICT | 本地修改和远程更新改了同一处 | 按冲突标记手动合并，解决后 git stash drop |
| 未跟踪文件被远程同名文件覆盖报错 | 远程新增了同名文件，本地也有同名新文件 | 备份后 git stash push -u，或重命名本地文件 |
| pull 提示 "Your local changes would be overwritten" | 本地已跟踪文件有未提交修改 | 先 stash，再 pull，然后 stash pop |
| rebase 卡到一半想放弃 | rebase 冲突过多 | git rebase --abort 回到 rebase 前状态 |
| merge 完成后想撤销 | 合并后发现问题 | git reset --hard HEAD~1 或 git revert 合并提交 |
| stash 列表太乱搞混记录 | 多次 stash 忘了内容 | git stash show stash@{n} 查看改动，恢复时指定编号 |
| 不确定远程更新内容就拉取 | 怕别人代码有问题 | 先 git fetch 再 git log origin/分支名 --oneline 预览 |
这里面最值得提醒的是 git rebase --abort。这个命令可以在 rebase 进行中随时放弃操作，回到执行 rebase 之前的状态，前提是你没有在中途手动解决冲突并 git add 后又提交。只要你还在 rebase 过程中，abort 都是安全的退路。
6.2 我踩过的几个真实坑
先说 stash 丢失的坑。某次我在本地改了很多内容，没有 commit，直接执行了 git stash push -u，结果工作区被清空。后来因为急着处理另外一件事，忘了 stash 的存在，第二天才发现。幸好我在 stash 前养成了 git stash list 的习惯，最后靠 git stash pop stash@{2} 找回了改动。这件事教会我两件事：一是 stash 记录要命名，二是 stash 之后尽快恢复或至少记录 stash 编号。
再说自动 merge 的坑。有一次我拉取远程更新，Git 自动合并成功了，我以为是安全的，没有执行测试直接推到了远程。后来同事反馈某功能逻辑不对，排查发现自动合并把双方代码按某种方式拼接起来，虽然语法正确，但逻辑路径产生了错误。自动合并成功不等于合并正确，这个认知太重要了。
最后是 rebase 和 merge 混用的坑。团队里大家约定用 rebase，但有人不熟悉，直接拉取了默认配置的 git pull，产生了 merge 提交。历史一混乱，后续 rebase 就冲突不断。这个问题不是技术问题，而是团队规范问题。把 merge 和 rebase 的使用规则写进 README，新成员入职先读这一页，能省下大量沟通成本。
7. 把安全拉取变成肌肉记忆的几条建议
操作层面的内容讲完了，再说说如何把这些流程变成日常习惯。毕竟理论再多，记不住、不常用，等于白搭。
7.1 给 Git 配置一个"安全默认值"
我强烈建议在全局配置里设置 pull.rebase，让默认的 git pull 行为变成 rebase 而不是 merge：
bash复制git config --global pull.rebase true
git config --global rebase.autoStash true
pull.rebase true 让每次 git pull 默认采用 rebase 策略，历史保持线性。rebase.autoStash true 让 git pull 在遇到本地未提交修改时自动 stash，拉取完再恢复。
这样的配置有一个明显好处：即使你某天忘了手动 stash，直接执行了 git pull，Git 也会自动帮你完成"备份、拉取、恢复"的全流程，不会因为未提交修改而卡在中间。但注意，自动 stash 不等于不会冲突，如果恢复时遇到冲突，处理方式和前面讲的一样，同样要小心验证。
7.2 开发前想清楚"我这轮改动要提交吗"
好的 Git 使用习惯不是靠应急操作练出来的，而是靠日常规划养成的。我现在的习惯是，每开始一个新功能或者一个修复任务，先创建一个独立的分支：
bash复制git checkout -b feature/fix-login
在这个分支上做修改、提交，等代码稳定、测试通过后再合并回 develop 或 main 分支。这样做的最大好处是，远程更新可以随时在主分支上安全拉取，你的本地修改在自己的分支上受到保护，两者互不干扰。
如果没有分习惯用分支开发，那 "本地有修改时安全拉取远程" 就会成为常态烦恼。我记得刚开始工作那会，天天在 main 分支上直接改，每次拉取都提心吊胆，后来磨炼出了分支开发的好习惯，才发现原来没提交的修改根本不需要担心被覆盖，只要分支隔离就能安心。
7.3 团队协作中的拉取节奏
除了个人操作，团队协作的节奏也影响冲突发生概率。一个简单的建议：频繁、小步地拉取远程更新。不要等远程领先你三四十个提交再拉，那时候冲突概率大幅上升。每天开工前、午餐前、收工前各 git pull 一次，把冲突解决在萌芽阶段，每次处理的冲突量都不大。
如果发现远程更新经常和你改动的代码区域高度重合，说明你们的任务划分可能需要调整，或者代码耦合太重。这是更深的架构话题，但至少应该引起警觉。我碰过一个项目，三个人同时改同一个工具函数文件，几乎每次拉取都有冲突，后来大家约定把该文件拆分成几个独立模块，冲突显著减少。
最后分享一点个人体会
算下来我处理"本地有修改时拉取远程更新"这个场景，从最早的惊慌失措到现在的从容应对，靠的不是什么神秘技巧，就是一套稳定的流程加几条经验教训。每次收到远程更新提示，我先 git status，再 stash，然后 git pull，结束后恢复并测试，整个过程基本成了肌肉记忆，十分钟内完成，期间不会有任何心跳加速的时刻。
如果你目前还处于"看到冲突就心慌"的阶段，记住一句话：Git 的设计给了你足够的退路，大部分误操作都可以撤销或者挽回，你唯一要做的就是在操作前多想一步。多花两分钟做备份，比事后花两小时恢复代码划算太多了。希望这篇总结能让你少踩几个坑，以后遇到类似场景，也能像处理日常事务一样淡定地完成拉取。