git status 是定位冲突文件的最直接方法，它会明确列出处于“Unmerged paths”状态的文件，如“both modified”“deleted by them”等，这些是 Git 划出的重点冲突项，需优先确认而非直接编辑。
git status 一眼定位冲突文件
执行 git status 是最直接的入口。它不会告诉你“哪里错了”，但会明确列出所有处于 Unmerged paths 状态的文件，比如：
both modified: src/utils/date.jsdeleted by them: package-lock.json
注意这些关键词：both modified（双方都改了）、deleted by us/them（你删了/对方删了）、added by them（对方新增了你没拉的文件）。这些不是警告，而是 Git 在帮你划重点——哪些地方它无法自动决定。
别跳过这步直接打开编辑器。先确认是不是真有冲突：如果 git status 没提任何 Unmerged，那所谓“冲突”可能是误判（比如只是本地有未提交修改）。
手动编辑时识别
打开冲突文件后，你会看到类似这样的三段式结构：
<<<<<<< HEAD export const formatDate = (date) => date.toISOString(); ======= export const formatDate = (date) => date.toLocaleString(); >>>>>>> origin/main
这不是 bug，是 Git 插入的“决策锚点”：
到 <code>=======之间是你本地分支（当前所在分支）的代码-
=======到>>>>>> origin/main之间是远程分支（通常是origin/main）的代码 - 中间没有“共同祖先”行——Git 默认不显示 base 版本，除非你配置了
merge.conflictStyle = diff3
常见误操作：只删掉标记，不检查逻辑。比如上面例子中，两个 formatDate 实现逻辑不同，直接保留一个可能破坏依赖它的组件。务必结合 git log -p src/utils/date.js 看谁在什么时候改了什么。
用 git mergetool 启动可视化工具
命令行看标记容易漏行，尤其当冲突分散在几十行里。运行 git mergetool 会按 .gitconfig 中 merge.tool 的设置启动图形化工具：
- macOS 用户可直接用系统自带的
opendiff（需提前配置git config --global merge.tool opendiff） - VS Code 用户推荐安装
GitLens扩展，右键文件 → “Resolve Conflict” 即可调出三栏视图 - IntelliJ IDEA 内置工具默认启用，冲突文件上右键 → “Git → Resolve Conflicts”
关键提醒：工具只是辅助，不替你做判断。P4Merge 显示四栏（base/local/remote/merged），Meld 只显示三栏（local/remote/merged），但无论哪种，最终合并结果都得你手动确认保存——保存即代表你认可该版本，Git 才允许你继续 git add。
解决后必须 git add 才算真正“解决”
很多人以为删完冲突标记、保存文件就完了。其实 Git 仍把该文件视为“未合并状态”，直到你显式执行：
git add src/utils/date.js
这时文件才会从 Unmerged paths 移入 Changes to be committed。如果忘了这步就直接 git commit，Git 会报错：Committing is not possible because you have unmerged files.
特别注意 package-lock.json 这类自动生成文件：不要手动删冲突标记。应先 npm install 或 yarn install 生成新锁文件，再 git add package-lock.json ——否则很可能引入依赖不一致问题。
