如果你和我一样，有过这种经历：改了一堆本地代码还没提交，远程同事又推了新东西，你在终端敲下 git pull，Git 突然冒出一句 “Your local changes to the following files would be overwritten by merge”，又或者更吓人地看到本地刚才还在的改动瞬间没了——那你肯定想知道一件事：git pull 拉取远程仓库代码时，到底怎么才能防止本地代码被改坏、被覆盖、被重排。不要慌，这篇文章就把这块事彻底捋清楚，从 Git 默认的保护机制，到 stash、autostash、rebase 模式下的时序，再到被迫强制同步时的保命姿势，一步不落全给你拆开讲。不管你是第一天用 Git 的新手，还是早就被覆盖过几次的“受害者”，都能从这里找到能直接照着抄的方案。

先给结论：Git 本身在 pull 合并时是有安全保护的，不会随便用远程版本覆盖你还没提交的本地修改。真正把你本地代码搞没的，绝大多数是你自己在错误的时机用了 git reset --hard、git checkout、git clean，或者在没理解 rebase 规则的情况下强行拉取。所以我们要做的不是“阻止 pull 本身”，而是管好本地工作区的脏状态，让每一步操作都在可控范围内。下面我按场景一条一条展开。

1. 问题场景：为什么 pull 有时候会动我的本地代码

1.1 先看清 git pull 的真面目

Git 的 pull 从来不是一条魔法命令，它是“取回远程更新”和“合并到当前分支”两件事的合成品。默认情况下，git pull 等价于先执行 git fetch origin，把远程仓库最新提交下载到本地的 origin/xxx 引用里，再执行 git merge origin/xxx，把这些远程提交合并到你当前所在的分支。

merge 发生在提交层面，它要看的是“当前分支最新的 commit”和“远程分支最新的 commit”。如果这个过程中涉及到的文件本身会产生冲突，Git 会尝试做三方合并，如果本地工作区里还有你没提交但修改过的内容，情况就变得微妙了。

举个例子，你的工作区里 login.js 被改了一半，同时远程仓库的 login.js 也被别人改了。当 git merge 想把这个文件更新到工作区时，它就碰到了矛盾：它不知道你当前工作区的修改应该保留还是丢弃，只能放弃合并并报错。这就是那句 “cannot pull with rebase: You have unstaged changes” 或者 “Your local changes ... would be overwritten by merge” 的由来。

反过来，如果远程更新完全不碰你改过的文件，那 git pull 会非常顺利地完成，你的本地修改甚至还会被悄悄保留下来。很多人产生“本地代码被修改了”的错觉，其实是合并过程中 Git 把本地依赖的某个中间文件也一并更新了，导致运行时行为变了——注意，这不叫覆盖，这叫依赖变化。

1.2 真正危险的覆盖来自哪里

假如你的本地修改全部都已提交，或者你压根没有未提交的改动，那 pull 覆盖的只会是“你提交历史里的某一个 commit”，只要冲突不是很多，Git 都能处理。真正会瞬间清空你桌面上正在编辑的代码文件的，是下面几类命令：

• git reset --hard origin/main：直接把本地当前分支强制重置到远程分支的最新提交，工作区和暂存区都会被同步覆盖，本地所有未提交改动全部丢弃。
• git checkout -- <file> / git restore <file>：把某个文件还原成 HEAD 或指定提交的版本，本地未提交改动被覆盖。
• git clean -fd：删除所有未跟踪文件和目录，你新创建但还没加入版本控制的“半成品”文件可能直接蒸发。
• 某些 GUI 工具在配置不当的情况下，比如把 “pull with force” 或者 “reset to remote” 当默认操作，也可能一步到位。

所以，如果你担心的是“本地代码被修改”，请先区分：你是在担心未提交的修改丢失，还是在担心已提交但尚未推送的提交被远程覆盖。这两者应对策略完全不同。后续章节我会分别给出标准操作。