Git Pull 冲突时，先通过VS Code源代码管理侧边栏（❗图标）或git status定位未合并文件，再用内置按钮或手动编辑保留完整冲突标记结构，解决后必须git add暂存，最后git commit。
Git Pull 报 conflict 怎么快速定位冲突文件
VS Code 里 git pull 失败后，别急着删分支或硬重置。冲突本质是 Git 发现同一段代码在本地和远程都有修改，且无法自动合并。VS Code 底部状态栏会显示「有未合并的更改」，但更可靠的是立刻看源代码管理侧边栏——所有冲突文件都带 ❗ 图标，点开就能看到高亮标记的冲突块。
常见错误现象：error: Your local changes to the following files would be overwritten by merge 或 CONFLICT (content): Merge conflict in xxx.js。这类提示说明 Git 已停在合并中途，工作区处于「未完成合并」状态，此时 git status 会明确列出 Unmerged paths。
- 优先用 VS Code 内置的「接受当前更改 / 接受传入更改 / 接受两者」按钮，比手写
块更安全 - 如果文件太多，先执行
git diff --name-only --diff-filter=U快速列出所有未合并文件 - 别直接关 VS Code —— 冲突未解决时关闭编辑器，下次打开仍会停留在相同状态，但可能丢失部分临时高亮
VS Code 里怎么手动编辑冲突块才不破坏 Git 标记
VS Code 的冲突编辑器默认展示三栏：当前（local）、传入（incoming）、合并结果。但如果你切到纯文本模式手动改，必须严格保留 Git 的分隔符，否则 git add 会失败或提交脏数据。
关键不是删掉 ，而是确保每处冲突块结构完整：
<<<<<<< HEAD
console.log('local change');
=======
console.log('remote change');
>>>>>>> origin/main
- 删掉任意一行分隔符（比如漏了
>>>>>> origin/main），git add会报错fatal: cannot lock ref 'HEAD': is at ... but expected ... - 如果只想要一边的逻辑，删掉整块包括分隔符，再补上你选的那一行代码即可，不用留空行
- 多个冲突块出现在同一文件？每个块都得单独处理，VS Code 会逐个高亮，别跳着改
解决完冲突后 git add 不生效？检查 staging 状态
点完「接受」按钮或手动改完保存后，VS Code 左下角可能还显示「有未暂存的更改」，这是正常现象——Git 还没把解决后的文件标记为已合并。必须显式执行 git add <file></file> 或在 VS Code 源代码管理视图里勾选文件并点击「+」号。
容易踩的坑：git commit 前没 git add，会导致提交内容仍是冲突前的状态，甚至把 块一起提交上去。
- 执行
git status，确认文件从Unmerged paths变成Changes to be committed - 如果用了 VS Code 的「全部暂存」按钮，注意它不会自动包含新创建的文件，冲突解决中新增的文件要单独加
- 不确定是否干净？运行
git ls-files -u，输出为空才代表所有冲突已标记为已解决
不小心跳过冲突直接 push 会怎样
VS Code 的「同步更改」按钮（⬆️⬇️图标）本质是 git pull && git push，但如果 pull 阶段有冲突而你没注意到，它不会自动跳过，而是卡住不动。真正危险的是：你在终端手动 git pull --rebase 后遇到冲突，resolve 完忘了 git rebase --continue，就直接 git push —— 此时 Git 会拒绝，报错 Updates were rejected because the tip of your current branch is behind。
这不是 VS Code 的问题，是 Git 保护机制。但很多人误以为「push 成功了」，其实只是推了旧提交。
- 只要
git status显示rebase in progress，就绝不能git push - 想取消？用
git rebase --abort，回到 pull 前状态，再老实用 merge 方式处理 - 团队协作中，如果已强制 push 覆盖了远程历史，立刻通知队友，因为他们的本地分支很可能已损坏
