在日常开发中，我们经常会遇到这样一个场景：
$ git pull origin
error: Your local changes to the following files would be overwritten by merge:
xxx
Please commit your changes or stash them before you merge.
Aborting
很多人第一反应是：
👉 “Git 怎么又抽风了？”
其实不是 Git 的问题，而是它在保护你的代码。
🧠 问题本质
这个报错背后的逻辑其实很简单：
👉 远程有更新 + 本地也修改了同一文件 = 潜在冲突
Git 不确定你是否愿意丢失本地修改，所以直接拒绝 pull。
换句话说：
状态
说明
远程代码更新
有新提交
本地文件已修改
未 commit
结果
❌ Git 阻止 merge
🛠️ 三种标准解决方案
🥇 方案一：提交本地代码（推荐）
如果你的修改是完整且需要保留的，直接提交：
git add .
git commit -m "feat: 本地修改"
git pull origin <branch>
👉 优点：
-
安全
-
代码有记录
-
符合团队协作规范
👉 适用场景：
-
功能开发已完成
-
修改具备阶段性成果
🥈 方案二：stash 暂存（最常用）
如果你的代码还没写完，不想提交：
git stash
git pull origin <branch>
git stash pop
流程解释：
-
git stash👉 暂存当前修改 -
git pull👉 拉取远程代码 -
git stash pop👉 恢复本地修改
👉 优点：
-
不污染 commit 记录
-
灵活方便
👉 注意：
stash pop之后可能仍然会有冲突，需要手动解决
🥉 方案三：放弃本地修改（慎用）
如果本地改动不需要了：
git restore .
git pull origin <branch>
⚠️ 风险提示：
👉 所有未提交的修改会被永久删除！
⚠️ 一个容易忽略的坑
很多人习惯这样写：
git pull origin
但实际上，这样是不严谨的。
如果你当前在 feature 分支，正确写法应该是：
git pull origin feature/xxx
👉 否则可能会拉取默认分支（如 main / develop），引发不必要问题。
🔥 推荐实践（团队开发建议）
结合实际开发经验，推荐优先级：
-
✅ 开发完成 → commit 再 pull
-
✅ 开发中 → stash 再 pull
-
❌ 不要轻易 restore（除非确认不要代码）
💡 一句话总结
👉 Git 并不是不让你 pull，而是在提醒你：
“你的代码可能会被覆盖，请先做选择。”
🚀 延伸思考
这个问题本质上反映的是：
-
本地开发节奏 vs 远程协作节奏
-
代码状态管理能力
-
Git 使用熟练度
掌握 commit / stash / restore 的使用时机，是从“会用 Git”到“用好 Git”的关键一步。
如果你也遇到过类似问题，可以在评论区交流你的处理方式 👇
