GoLand 不解决“项目历史提交冲突”，实际是 Git 合并/变基时的内容冲突；红色标记表示未完成操作，需在 Git 工具窗口右键 Resolve Conflict 调出三窗格界面手动处理，解决后须点击 Apply 并提交。
GoLand 本身不解决“项目历史提交冲突”——Git 没有这种冲突类型。你真正遇到的，是 git merge、git rebase 或 git pull 过程中产生的**内容冲突（content conflict）**，即多个分支修改了同一文件的同一行。GoLand 提供的是本地可视化解决工具，不是“修复历史”的魔法。
为什么在 Git Log 里看到红色冲突标记？
这不是 Git 历史出错，而是 GoLand 在 Git Log 视图中高亮显示了**尚未完成的合并/变基操作**。它只是告诉你：当前 HEAD 处于一个未完成的合并状态（merging 或 rebase），工作区存在未解决的冲突文件。
- 现象：Git 工具窗口顶部显示 “Merging into …” 或 “Rebasing branch …”，提交列表中某处出现红色感叹号或 “Conflicts” 节点
- 本质：Git 已暂停操作，等待你手动处理冲突文件，而非历史记录本身损坏
- 关键点：
git status会明确列出Unmerged paths—— 这些才是你要动手的文件，不是整个历史要重写
用 GoLand 内置工具打开冲突文件的正确入口
别在编辑器里直接双击冲突文件——那只会显示原始冲突标记（<<<<<< HEAD），没法调出三窗格对比界面。
- 在 Git 工具窗口（Alt+9）中找到带红色标记的文件，右键 → Resolve Conflict
- 或点击 Git 工具窗口顶部的 Conflicts 节点，再选文件点击 Manual Resolve
- 或在编辑器中打开冲突文件后，按
Ctrl+Click（macOSCmd+Click）冲突块旁的灯泡图标，选择 “Resolve with GoLand” - 错误做法：用
git checkout --ours后再点 Resolve —— 此时文件已无冲突，GoLand 不会弹出三窗格界面
三窗格界面里最容易忽略的细节
左侧（Local）和右侧（Incoming）都是只读，但中间（Result）是可编辑的完整编辑器——这点常被当成“只预览”而错过直接修改机会。
-
Base版本（初始中间内容）不是“原始文件”，而是两个分支共同祖先版本，可能比你预期更旧 - 点击冲突块右键菜单里的 Resolve using Left / Resolve using Right 是快捷方式，但无法处理“两边都保留一部分”的混合修改
- 简单冲突（如一行两端被不同分支修改）会出现 Solve simple conflicts 按钮，但它不会自动触发——必须手动点，且仅对当前选中冲突生效
- 中间窗格支持全功能编码：补全、格式化、甚至运行小段代码验证逻辑，别只当它是文本框
解决后必须做的两件事，缺一不可
GoLand 解决完冲突只是改了文件内容，Git 状态仍为 “unmerged”。它不会自动 git add 或 git commit。
- 确认所有冲突文件在中间窗格里都已清理干净（无
<<<<<<标记），然后逐个点击窗格下方的 Apply 按钮（不是“OK”） - 回到 Git 工具窗口，你会看到这些文件从 “Conflicts” 节点移到 “Local Changes” 下，此时必须右键 → Commit Directory 或手动
git add+git commit - 如果中途想放弃：直接点 Git 工具窗口顶部的 Abort Merge（不是关闭对话框），否则残留的 .git/MERGE_HEAD 会让下次操作继续报错
真正的难点不在操作步骤，而在判断哪边逻辑该保留——GoLand 只提供界面，不替代代码理解。合并前多看一眼 git log -p 或分支差异，比依赖三窗格自动推断更可靠。
