冲突文件在Version Control窗口（Alt+9）的红色“Merge Conflicts”节点下；未出现该节点说明尚未真正触发冲突；双击文件进入三向合并视图，中间为base、左为mine、右为theirs；解决后需Apply、Add、Push三步操作，属性冲突则需在Update Info中手动处理。
冲突文件在哪？别翻文件树，直接看 Version Control 窗口
WebStorm 不会把冲突文件混在“未提交更改”里，也不会靠 git status 去猜。它在 Version Control 工具窗口（默认 Alt+9）中单独开辟一个红色节点，叫 Merge Conflicts。点开它，所有冲突文件一目了然。
如果没看到这个红色节点，大概率是：git merge 根本没执行成功，或者目标分支压根没新提交——不是工具失灵，是还没真正触发冲突。
双击任一文件，立刻进入三向合并视图；别手动用编辑器打开源码去搜 <<<<<< HEAD，那是绕远路。
三向合并界面里，“Mine”“Theirs”“Base”到底谁是谁？
中间面板是 base（两个分支的共同祖先），左边是 mine（你当前分支的修改），右边是 theirs（你要合并进来的那个分支的内容）。这个顺序固定，不随你当前在哪个分支上而变——哪怕你在 main 上合并 feature/login，右边永远是 feature/login 的改动。
右键高亮冲突块，能快速选：
- Resolve using Mine：删掉右边全部，只留左边逻辑
- Resolve using Theirs：覆盖你本地所有改动，适合你只改了个注释而对方重写了函数
- Apply All Non-Conflicting Changes：只合并无交集的行，对带标记的区域完全不动
注意：Resolve simple conflicts 按钮只对“单边增一行”“单边删一行”这类线性差异生效；一旦出现 if 分支互斥、JSON 字段同名不同值，它就静音——必须手动进中间面板编辑，并亲手删掉 <<<<<< / ======= / >>>>>> 这三行标记，否则 Git 仍认为文件处于冲突状态。
中间面板改完就完事了？不，漏这三步等于白干
中间面板是唯一有效的“解决区”，但很多人点了 Apply 就以为结束，结果：
- 提交时报错：error: cannot lock ref 'refs/heads/main': is at ... but expected ...，因为冲突标记还在
- 函数签名不兼容、变量作用域被意外扩大，静态检查没报错，运行时才崩
- 合并后空格/缩进不一致，引发下一次冲突
建议操作：
- 改完中间面板后，按 Ctrl+Alt+O（Optimize Imports）和 Ctrl+Alt+L（Reformat Code）顺手格式化
- 点 Apply 是把内容写回文件，但 Git 还不知道你已认领结果；必须接着右键该文件 → Git → Add（或直接 Ctrl+K 提交）
- 合并成功后，记得 VCS → Git → Push，否则别人根本看不到你的合并提交
属性冲突（.gitattributes、chmod、symlink）根本不会出现在合并视图里
WebStorm 的图形化工具只处理文本内容冲突，对属性类变更完全不感知。这类冲突不会标红在 Merge Conflicts 节点下，而是藏在 Version Control 窗口的 Update Info 标签页里，类型标注为 property conflict。
它不给你左右对比，也不高亮代码——你得自己：
- 运行 git status -v 看输出里有没有 changed in the index 或 needs merge
- 查 git ls-files --stage | grep 100644 判断是不是权限变更
- 解决后必须右键该文件 → Resolve → Mark as resolved，否则 WebStorm 一直卡着不放
这类问题容易被忽略，因为界面太安静了——没红标、没弹窗、没提示，但它真实存在，且阻断后续所有 Git 操作。
