塞音菩光日常开发里被 git pull 坑过的人绝对不在少数。高高兴兴敲完 git pull origin main，结果本地改了半天的文件直接被覆盖，甚至还没来得及 commit 的代码直接找不回来，那种感觉谁遇到谁知道。本文就围绕“git pull 拉远程仓库代码时如何防止本地代码被修改”这个核心痛点展开，把底层原理、四种安全方案、冲突场景和实操技巧一次讲透，适合刚接触 Git 的新人，也适合被覆盖问题困扰过、想彻底搞懂保护机制的开发者。
1. 先从根上理解：pull 为什么会动你的本地代码
要想不被坑，得先搞清楚 Git 是怎么“坑”你的。很多人在 git pull 之前根本没意识到：这条命令背后其实是两步操作——先从远程仓库 fetch 最新提交到本地缓存的远程分支，再把远程分支合并到当前分支，而第二步合并才是真正可能改写你本地代码的地方。
这不是我编出来的，你可以直接看一下 Git 文档对 git pull 的定义：它等价于 git fetch 加 git merge。也就是说，当你执行 git pull 时，Git 默认会把你当前分支和远程跟踪分支做一次三方合并。
这里涉及一个重要的背景知识：Git 管理代码的“三棵数”模型。
- 工作区（Working Directory）：你实际能看到的、正在编辑的文件。
- 暂存区（Index/Stage）：你通过
git add放进去的区域，记录了下一次 commit 要包含的快照。 - 本地仓库（Local Repository / HEAD）：已经通过
git commit固化下来的历史记录。
git pull 中的 merge 步骤，本质上是把远程分支的最新提交和你的本地提交做合并，合并结果会同时影响工作区和暂存区。如果在合并时，某个文件在远程有更新，但你在本地也修改过且未提交，Git 就会陷入两难：到底是保留你的修改，还是用远程的版本覆盖？正是这种“两难”导致了各种覆盖、冲突或者直接拒绝合并的问题。
再补充一点：git pull 在默认配置下还会尝试 fast-forward（快进合并）。当你本地没有新增提交、只是落后于远程时，Git 会直接把当前分支指针快速移动到远程分支的最新提交上。这个过程既快又顺畅，看起来是无害的，但它非常容易掩盖一个问题——如果你本地有未提交的修改，碰巧这些文件又被远程更新了，Git 大概率会直接报错，但如果你之前执行过某些比较激进的操作（比如 stash 没存干净、checkout 强制切换分支），那本地修改就可能被悄悄丢掉。
知道这些原理之后，你就能明白：防止 pull 修改本地代码的关键，是在 pull 之前对“本地未提交的修改”主动做一次“兜底保护”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 事前预防：给本地代码加“保险”的两种官方姿势
2.1 姿势一：用 git stash 临时收好本地修改（推荐）
git stash 是 Git 提供的一个“临时储物间”命令。它会把当前工作区和暂存区中未提交的修改保存到一个栈结构中，然后把你的工作区恢复到和 HEAD 一致的状态。等到远程代码拉取完成，再通过 git stash pop 把修改取回来。
最简单的保护流程是这样：
bash复制# 1. 查看当前状态，确认有哪些改动
git status
# 2. 把未提交的修改暂存起来
git stash push -m "wip: 我还没写完的改动"
# 3. 确认工作区已干净
git status
# 4. 放心地拉取远程代码
git pull origin main
# 5. 把之前暂存的修改恢复到工作区
git stash pop
注意 git stash push -m 可以给每个 stash 加一条说明信息，当 stash 多了的时候，你能清楚知道哪一条对应哪次改动。如果只用 git stash 而不加参数，也是可以的，只是如果积压多了就不好认了。
这里有个容易踩的坑：git stash pop 并不是 100% 无冲突恢复。如果你暂存的修改和远程新拉下来的代码在同一个文件的同一行都有变动，pop 的时候就会产生冲突。Git 会尝试自动合并，但如果实在合并不了，它会直接把有冲突的文件标记出来，放进工作区，而不是自动丢弃你的修改。这时候你需要手动解决冲突。我个人的建议是：pop 以后立刻检查 git status，看看有没有 UU 状态的文件，有冲突就赶紧处理。
2.2 姿势二：先 commit 再 pull（适合阶段性完成的改动）
如果你的本地修改已经是一个逻辑完整、能通过编译或者测试的阶段，那更推荐的做法是先 git commit 提交到本地仓库，然后再 git pull。
bash复制git add .
git commit -m "refactor: 完成模块A的重构"
git pull origin main
先把改动提交到本地仓库，意味着你的修改已经永久记录在 Git 历史里了。这样即使后续 merge 出问题，也可以通过 git reflog 找到你原来的提交，回到事发之前的状态。这比 stash 更安全，因为 stash 本质上只是“暂存”，很多人会忘记 pop 导致改动长期积压，最后甚至误以为丢失。
但要注意，commit 之后执行 git pull 如果产生冲突，处理起来要比 stash 场景复杂一点点。因为这时候你的本地提交和远程提交会形成两个分叉点，Git 需要做一次真正的三方合并，合并过程可能需要手动解决冲突，解决完以后还要再提交一次。
那“未完成”和“完成了”的界限怎么把握？我自己的标准是：只要代码能编译通过或者不影响其他同事的代码，我就提交到本地。哪怕提交信息写的是“wip: 局部改动，不一定对”，也比裸奔在工作区里强。因为你永远不知道一次 pull 会带来什么意外。
3. 主动改造运行机制：让 pull 不再“轻举妄动”
3.1 修改 pull 默认行为：从 merge 切换到 rebase
前面说过，git pull 默认执行 merge。merge 的特点是会产生一个合并提交，并且会把两个分支的历史交织在一起。但还有一种 pull 策略是 rebase，它做的事情是：把你本地独有的提交先临时拿下来，把远程提交拉下来，然后再把你本地的提交重新“叠放”到远程最新提交之上。
使用 rebase 方式执行 pull 的写法是：
bash复制git pull --rebase origin main
rebase 同样会检查你工作区是否有未提交的修改。实际上，无论用 merge 还是 rebase，只要工作区有未提交的修改、且这些文件在远程也有对应更新，Git 都会先停下来，拒绝执行，防止盲目覆盖。
那 rebase 方式本身对“保护本地代码”有什么额外价值呢？主要是它避免了无意义的合并提交。举个实际场景：你本地有一个提交 A，远程有同事提交了 B、C。如果用 merge，会产生一个合并提交 M，历史变成 A -> M <- C，看 log 的时候会比较乱；如果用 rebase，历史会变成 B -> C -> A'，你的提交 A 被重新放到最顶端，历史是线性的，非常干净。
不过 rebase 有个需要特别留意的点：永远不要对已经推送到远程共享分支的提交做 rebase。一旦 rebase，就会改变提交的 SHA-1 哈希值，如果别人已经基于你的旧提交开发，他的本地历史就会和远程历史分叉，这会引发一串连锁冲突。
3.2 全局配置：设置 pull 的默认行为
如果你和我一样，更喜欢 rebase 方式的线性历史，可以通过 Git 配置把默认行为固定下来：
bash复制git config --global pull.rebase true
你也可以只对当前仓库生效：
bash复制git config pull.rebase true
pull.rebase 的取值可以是 true、false 或者 merges。true 表示普通 rebase；merges 表示在 rebase 时保留本地合并提交的结构。如果你拿不准，从 true 开始就好。
还有另一个相关的配置项 pull.ff，默认是 only，只允许 fast-forward。不过实际项目中，这个配置用得比较少，了解即可。
3.3 更稳妥的混合操作：先 fetch 再手动合并
有时候，我不确定本地改动和远程改动的冲突范围有多大，直接 git pull 心里没底。这时候我会拆开执行 fetch 和 merge，给自己留一个观察窗口。
bash复制# 第一步：只拉取远程最新提交到本地远程跟踪分支，不动工作区任何文件
git fetch origin
# 第二步：对比本地分支和远程分支的差异
git log --oneline HEAD..origin/main
git diff --stat HEAD origin/main
# 第三步：确认差异范围后，再决定怎么合并
git merge origin/main
fetch 是“绝对安全”的操作，因为它只更新本地仓库里记录远程分支的引用（比如 origin/main），完全不会碰你的工作区文件。你可以在 fetch 之后从容地查看差异，看看远程改了哪些文件、和你本地改动有没有交集，然后再决定是用 git merge 还是 git rebase。
如果发现冲突风险较高，你还可以在 merge 之前用 git stash 把你的改动收起来，merge 完再 pop；如果在 merge 过程中出现冲突，可以随时用 git merge --abort 放弃合并，回到 merge 之前的状态。
这句话值得单独强调：在动手 merge 之前，做任何你需要的备份和检查，永远比事后补救来得轻松。
4. 如果真的冲突了：处理流程和防止“二次伤害”
4.1 冲突发生后的正确反应
先说一个反直觉但非常重要的点：当 Git 报告冲突的时候，你的代码并没有坏，只是被放在了一个等待人工决策的状态。
冲突发生时，Git 会做这三件事：
- 在有冲突的文件里加入冲突标记，格式长这样：
text复制<<<<<<< HEAD
这是你本地当前分支的内容
=======
这是远程分支或合并来源的内容
>>>>>>> origin/main
-
把有冲突的文件标记为 Unmerged，在
git status里这些文件状态是UU。 -
停下整个合并流程，等你处理完冲突并执行
git add加git commit。
处理冲突的标准流程是：
bash复制# 1. 查看哪些文件冲突
git status
# 2. 逐个打开冲突文件，搜索 <<<<<<< 标记，手动保留正确内容
# 保留完之后删掉 <<<<<<<、=======、>>>>>>> 这三行标记
# 3. 把解决完的文件标记为已暂存
git add 文件名
# 4. 确认所有冲突都已解决
git status
# 5. 提交合并结果
git commit
这里有一个非常关键的技巧：如果你想放弃所有本地修改、完全以远程为准，可以用的命令是：
bash复制git checkout --theirs 文件名
如果想以本地修改为准、放弃远程的变动，则用：
bash复制git checkout --ours 文件名
但是，不同场景下 --ours 和 --theirs 指代的内容可能不一样。在 git merge 的过程中，ours 是你当前所在的分支（也就是你执行 merge 前所在的分支），theirs 是你要合并进来的分支。在 git rebase 的过程中，语义正好相反——ours 变成了 rebase 的基底（往往是远程分支），而 theirs 才是你自己原来的提交。很多人就是在这里被绕晕的，所以我建议：拿不准的时候不要偷懒，直接打开文件手动编辑，这比赌 --ours/--theirs 的含义要稳妥得多。
4.2 设置 diff 工具，减少人工编辑成本
如果团队里经常出现复杂冲突，我建议配置一个可视化合并工具。以流行的 VS Code 为例，你可以这样合并：
bash复制git config --global merge.tool vscode
git config --global mergetool.vscode.cmd 'code --wait $MERGED'
保存配置后，遇到冲突时执行 git mergetool，VS Code 会直接打开三栏式合并界面：左边是本地版本，右边是远程版本，中间是合并结果。你可以通过点击按钮快速选取左右任意一侧内容，或者手动编辑中间区域。
经过配置之后，git mergetool 会自动打开配置的编辑器；手动打开 VS Code 处理也行，只要在文件保存后回到 Git 命令行执行 git add 即可。
4.3 如何找回被覆盖、被误删的本地代码
有些人可能在没做任何保护的情况下就直接执行了 pull，结果发现本地文件被覆盖甚至丢失，这时候别慌，Git 的后悔药有没有，取决于你的操作路径。
第一颗后悔药是 git reflog。只要你的改动曾经被 git commit 过，哪怕后来被 reset、rebase、merge 搞乱了，都可以通过 reflog 找回。
bash复制git reflog
这个命令会列出本地仓库 HEAD 指针的所有历史移动记录。找到你改动还在的那条记录，记下对应的哈希值，然后执行：
bash复制git cherry-pick 哈希值
或者用 git checkout 哈希值 -- 文件路径 把某个文件恢复到当时的版本。
第二颗后悔药是 git fsck --lost-found。如果你执行过 git stash drop 或者 git reset --hard 等操作，一些被解引用但还没被垃圾回收的 commit 对象会变成悬空对象，同样可以通过 fsck 找回来：
bash复制git fsck --lost-found
如果输出里有 dangling commit 之类的条目，这些就是可能被你“弄丢”的提交。
但必须承认，如果你从未 commit、从未 add、也没 stash，只是在一个干净的工作区上直接 checkout 切换到了某个分支，覆盖了你手动创建但没有被 Git 跟踪的文件，那 Git 确实无能为力。所以很多经历过一次事故的开发者，会养成人手一个备份目录的习惯，把重要的工作文件定时复制一份到仓库外的目录里，这操作听起来很“土”，但关键时刻能救命。
5. 进阶保护：让特定文件永不参与 pull 合并
5.1 skip-worktree：把不想动的文件“钉”在本地
有一种特殊场景，既不想 commit 也不想 stash，但你就是不想让某个文件（比如本地配置文件、密钥文件）被远程更新覆盖。举一个最常见的例子：项目里有一个 application.yml，本来是所有人的公共配置模板，远程偶尔会更新公共部分，但你在本地改了几个私有配置项，比如数据库地址和账号密码，你不想每次 pull 都去重新改一遍。
Git 提供了一种非常硬核的保护方式——skip-worktree 标记。设置之后，Git 会忽略该文件在工作区的改动历史，pull 时会跳过对这个文件的合并。
bash复制git update-index --skip-worktree application.yml
把这个标记取消恢复正常的命令是：
bash复制git update-index --no-skip-worktree application.yml
查看有哪些文件被设置了该标记：
bash复制git ls-files -v | grep '^S'
skip-worktree 会把文件标记为一个小写的 s。常见输出中带 S 前缀的就是被跳过的文件。
这里要特别强调一个类似命令的差异：assume-unchanged（标记为 a）在某些场景下容易被误用，从实际项目维护的角度看，我更推荐 skip-worktree。assume-unchanged 更多是 Git 内部用于性能优化，它告诉 Git“我假设这个文件没改过”，适用于监控大量文件变化时的性能优化，如果误用，反而可能导致你的本地改动被忽略掉，非常危险。
5.2 通过 .gitignore 从源头隔离
如果你那些不想被 pull 影响的文件是新增的、完全独立的文件，最优雅的做法还是写入 .gitignore 文件，从源头告诉 Git“这些文件我不跟踪”。被忽略的文件会直接退出 Git 的版本管理和合并逻辑，pull 无论如何都不会碰他们。
常见需要加 ignore 的内容：
- 本地环境配置：
.env.local、config/private.json - IDE 个人配置：
.idea/workspace.xml、.vscode/settings.json - 构建产物和临时文件：
node_modules/、dist/、*.log
需要注意 .gitignore 只会影响尚未被 Git 跟踪的新文件。如果某个文件已经被跟踪（加入了版本库），再把它写进 .gitignore 并不会让 Git 停止跟踪它。此时需要先把它从版本控制中移除：
bash复制git rm --cached 文件名
--cached 是关键参数，它表示只把文件从 Git 的索引中移除，但保留工作区里的物理文件。执行完以后再配合 .gitignore 把它忽略掉，这样远程代码的后续更新就再也不会影响这个文件了。
5.3 处理换行符差异导致的“假修改”
有一个问题极其隐蔽，导致本地文件在 pull 时被改得乱七八糟，那就是行尾符（line endings）自动转换造成的假差异。Windows 上的文件默认是 CRLF（回车+换行），而 Linux/macOS 默认是 LF（仅换行）。如果团队成员的编辑器或者 Git 配置不一致，pull 下来以后你可能会发现：明明什么都没改，但 git status 显示大量文件被修改，而且 diff 显示每一行都变了。
解决方案是在仓库根目录创建或修改 .gitattributes 文件，明确指定文本文件的换行策略：
text复制# 让 Git 在提交时统一转成 LF，在 checkout 到本地时按操作系统默认方式转换
* text=auto
# 强制所有 .js/.ts/.md 等文件使用 LF
*.js text eol=lf
*.ts text eol=lf
*.md text eol=lf
同时把 core.autocrlf 配置统一：Windows 上推荐设置 true，macOS/Linux 上推荐设置 input：
bash复制git config --global core.autocrlf true
换行符问题是一个“看起来不重要、实际上非常毁效率”的坑。我见过团队里因为换行符不统一，导致每次 pull 都会有十几个文件出现假冲突，新人面对满屏 diff 一脸懵，老手也只能一次又一次地 git checkout -- 文件 帮忙恢复。用 .gitattributes 统一策略后，这个问题才终于从根上解决了。
6. 常见问题排查与安全操作速查
6.1 我该什么时候用 stash，什么时候用 commit
这是很多人纠结的问题。我给一个可直接参考的判断标准：
| 场景 | 推荐操作 | 原因 |
|---|---|---|
| 本地改动是零散草稿、还没想好怎么提交 | git stash push |
不污染提交历史，可随时 pop 回来 |
| 本地改动已逻辑完整、能编译通过 | git commit 后再 pull |
本地提交更安全，可通过 reflog 找回 |
| 本地有大量不想被远程影响的独立文件 | .gitignore 或 git rm --cached |
从源头隔离，pull 永不触及 |
| 只想看远程变化、暂不合并 | git fetch |
零风险，不碰工作区任何文件 |
如果你担心 stash 太多记不住内容，可以在 push 时加消息说明，查看所有 stash 用 git stash list，想恢复某一条特定 stash 用 git stash pop stash@{1}。
6.2 我执行了 pull 后看到一堆冲突，想退回之前状态
这个场景分两种情况。如果 merge 还在进行中、你还没手动解决冲突并提交，可以直接中止：
bash复制git merge --abort
如果执行的是 rebase：
bash复制git rebase --abort
如果 merge/rebase 已经完成，但你想回到 pull 之前的状态，用 git reflog 找到执行 pull 之前那条 HEAD 记录：
bash复制git reflog
git reset --hard HEAD@{2} # 2 换成你实际情况中的序号
注意 git reset --hard 会丢弃暂存区和工作区所有未提交的改动，执行前务必确认你已经没有重要的未提交内容，否则后果自负。
6.3 如何查看远程分支和本地分支的差异，避免盲目 pull
在我决定执行 pull 之前，最有价值的操作是提前知道本地和远程差多远、差什么。
bash复制# 先拉取远程最新信息
git fetch origin
# 看看本地分支落后了多少个提交、领先了多少个提交
git rev-list --left-right --count HEAD...origin/main
# 查看具体差异的文件列表
git diff --name-only HEAD origin/main
# 查看远程比本地多出来的提交
git log --oneline HEAD..origin/main
如果输出显示本地领先远程若干个提交（左边数字不为 0），说明你本地确实有属于自己的提交，这时候执行 pull 会触发合并甚至 rebase；如果显示只落后不领先，说明是干净的 fast-forward 场景，理论上 pull 会非常顺利。
6.4 如何防止“同事直接改了远程分支历史”引发的灾难
还有一种情况常见于团队协作不规范的场景：某个同事对已经推送过的提交做了 rebase 或者 force push，导致远程分支历史被重写。你本地的 origin/main 指向的提交在远程已经“不存在”了，这时候 pull 可能产生各种奇怪的冲突，甚至造成代码重复、提交丢失的假象。
遇到这种情况，最好的策略不是硬 pull，而是先和同事确认发生什么，再考虑是否要把本地分支重置到远程状态。如果本地没有任何独有提交，可以：
bash复制git fetch origin
git reset --hard origin/main
如果本地有独有提交，且确认这些提交不想丢，先创建备份分支：
bash复制git branch backup/我的本地修改
git reset --hard origin/main
这种操作尤其要谨慎，不要在一个工作日的下午手一抖就执行，最好在操作之前把 git status、git log --oneline -5 的截图发到群里留个底。
7. 最终实操经验与团队协作建议
在实际项目管理中，代码覆盖问题的“锅”往往不只在某个人身上。我经历过几次严重事故，最后都指向同一个根因：团队成员对 Git 的保护机制理解不一致，各自凭感觉操作。
所以除了掌握上面这些命令行技能，还有几条团队层面的建议，每一条都是拿真实教训换来的。
第一，给团队的 Git 配置统一标准。把 pull.rebase、core.autocrlf、merge.tool 这些关键配置写入团队的 onboarding 文档，新成员加入的第一天就按统一标准配置好，能避免大量低级冲突。
第二，推动代码评审流程，确保每个人不会把密钥、本地配置等敏感文件误提交到远程。很多本地覆盖问题的本质其实是“错误地跟踪了不该跟踪的文件”，如果从一开始就通过 .gitignore 和 git rm --cached 把私人文件清理出版本控制，后续的 pull 根本不会碰到它们。
第三，对于重要分支，开启分支保护规则，禁止直接 push 和强制 push，要求所有更改都通过 Merge Request 合入。这能在机制层面杜绝远程历史被乱改的情况。
第四，如果团队对 Git 操作普遍不算熟练，建议引入可视化工具（比如 VS Code 的 Git 图形界面、Sourcetree）作为辅助。可视化工具在处理冲突、查看分支关系方面确实更直观，但底层逻辑还是那几条命令——fetch、merge、rebase、stash、commit，把命令行理解透了，用工具时才能不慌。
我个人这些年养成的习惯，说起来很简单但很管用：每次执行 git pull 之前，强制自己先看一眼 git status，只要有红色或绿色的改动，就停一下，想清楚这些改动是“要保留的”还是“可以丢的”。要保留的就 stash 或 commit，可以丢的才让 pull 放心覆盖。这看起来是个笨办法，但它从根本上杜绝了“唉，我的代码呢”这类悲剧。
最后再分享一个小技巧：如果你觉得每次敲 git pull 之前都要做检查太繁琐，可以给终端配置一个 alias，把检查和拉取绑在一起。
bash复制git config --global alias.safe-pull '!git status --short && git pull'
以后执行 git safe-pull，会先打印当前工作区的改动清单再执行 pull。这样即便你忘了主动检查，命令本身也会提醒你。一个小小的 alias，关键时刻能救回半天的劳动成果。