查看冲突来源的日志
冲突暂停时加上该选项，可以把范围过滤到「两方历史上真正改动过」的提交，快速定位是谁、因为哪些提交引入了冲突。它只在存在未解决冲突时与普通日志不同，状态干净后输出与普通日志一致。
基本信息
| 用途 | 只列出导致当前冲突的提交 |
|---|---|
| 语法 | git log --merge -p -- <路径> |
| 配套选项 | --left-right 用左右标记区分提交来自哪一方 |
| 生效条件 | 仅在存在未解决冲突时进行过滤 |
| 使用顺序 | 先读提交信息，再决定冲突的取舍 |
典型使用场景
- 冲突涉及不熟悉的代码时先弄清改动来源
- 确认冲突是哪个提交引入的
- 比较双方改动的意图后再决定取舍
- 为冲突解决结果留下可追溯的判断依据
- 排查经常冲突文件的改动历史
常用示例
常用示例
git log --merge --oneline # 只列出涉及冲突的提交
git log --merge -p -- src/app.js # 查看该文件的相关改动内容
git log --merge --left-right --oneline # 用左右标记区分提交来自哪一侧
git log --oneline -- src/app.js | head # 对照完整历史，判断上下文输出读法
| 标记 | 含义 |
|---|---|
| 左侧标记 | 提交来自合并的当前分支一侧 |
| 右侧标记 | 提交来自被合并进来的分支一侧 |
| 提交信息 | 判断改动意图与上下文的依据 |
| 路径过滤 | 只看与冲突文件相关的提交 |
先读提交信息往往就能判断冲突的语义取舍，比盯着冲突标记逐行猜测高效得多。
只看一方的历史容易误解冲突成因，左右标记配合使用才能还原两边各自改了什么。
把提交信息与改动内容一起看：有些冲突源于对方修复了同类问题，直接取一侧反而会丢掉修复。
判断完冲突来源后，把结论写进提交信息或评审回复，后续再遇到同一文件冲突时能直接复用判断依据。