拉取代码冲突是Git提示需手动解决而非出错；遇“Automatic merge failed”应先运行git status查看冲突文件，再编辑解决或用--ours/--theirs快速取舍，切勿盲目hard reset。
拉取代码时遇到冲突，不是 Git 出错了，而是它在告诉你：你和远程分支对同一段代码做了不同修改，必须由你来决定最终保留什么。
git pull 报错 “Automatic merge failed” 怎么办
这是最常见的情况，命令行直接卡住，提示类似：
error: Your local changes to the following files would be overwritten by merge: src/utils/format.js Please commit your changes or stash them before you merge.
或者更典型的合并失败提示：
Auto-merging src/utils/format.js CONFLICT (content): Merge conflict in src/utils/format.js Automatic merge failed; fix conflicts and then commit the result.
- 先别慌——这不是仓库损坏，只是 Git 拒绝自动覆盖你的本地修改
- 运行
git status查看哪些文件处于both modified或unmerged状态 - 如果只是少量文本冲突，直接打开文件编辑；如果是大量冲突或二进制文件（如图片、.jar），优先考虑
git checkout --ours或git checkout --theirs快速取舍 - 注意：不要用
git reset --hard直接硬重置，除非你确认不需要任何本地改动
冲突文件里看到
这是 Git 插入的标准冲突标记，三段结构有明确含义：
-
<<<<<< HEAD后面是你当前分支（比如main）的代码 -
=======是分隔线 -
>>>>>> branch-name后面是远程分支（比如origin/main）带来的修改 - 你必须手动删掉这三行标记，只保留最终需要的逻辑，不能留任何一行
- 例如修复价格格式化函数时，两边分别返回
'￥'和'$'，你要根据业务决定用哪个，或改成可配置的写法
该用 stash 还是 commit 再 pull
取决于你本地改的是“临时调试代码”还是“已完成的功能”：
- 如果是调试残留、console.log、临时注释等非正式改动：
git stash→git pull→git stash pop。恢复时若再冲突，说明远程也动了同一处，需手动处理 - 如果是已验证通过的功能修改，建议先
git add .+git commit -m"feat: xxx"，再git pull。这样合并提交里能清晰体现你的原始意图 - 避免长期 stash 堆积——
git stash list能查看，git stash drop可清理过期项
怎么避免下次又撞上拉取冲突
预防比解决更重要，但关键不是“不冲突”，而是让冲突变少、变小、变容易处理：
- 每天开工第一件事：执行
git pull origin main（或你团队主干分支名），而不是等到要 push 才拉 - 改一个功能，尽量控制在 1–3 个文件内；大文件（如 XML、JSON 配置）尽量按 key 拆分，避免多人同时改同一段
- 团队约定：涉及公共工具函数、常量定义、接口响应结构的修改，提前同步，或加注释标明“此函数被 X 模块依赖”
- 别跳过
git status—— 它能提前暴露 untracked 文件与远程同名冲突、权限变更等隐形问题
真正难的从来不是识别冲突标记，而是在几十个冲突文件里快速判断哪一行改动来自谁、是否已被废弃、要不要合并逻辑而非简单取舍。这时候，看提交记录比看冲突内容本身更有用——用 git log -p -n 5 -- src/utils/format.js 快速回溯上下文。
