拉取代码冲突是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 插入的标准冲突标记，三段结构有明确含义：

Git Factory

为每个编码任务配置并管理独立的 Git worktree，支持并行分支和清晰的 PR 工作流，避免合并冲突。

下载

• 后面是你当前分支（比如 <code>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 快速回溯上下文。