要查冲突相关提交，需定位合并提交：git log --merges -n 5；再用 git diff ^1 ^2 查差异，或 git log --cherry-pick ^1...^2 查引发冲突的提交。
git log 怎么查到冲突相关的提交
冲突本身不会被记录为独立事件，Git 只记录每次 commit。但冲突通常发生在 merge 或 rebase 过程中，所以真正要查的是「哪些提交在合并时产生了冲突」——这得从合并提交（merge commit）入手。
合并提交是关键线索：它有两个父提交（HEAD^1 和 HEAD^2），冲突就来自这两个分支的差异。因此，先定位最近的合并提交：
git log --merges -n 5
这条命令列出最近 5 次合并提交。如果知道大概时间或分支名，可以加过滤：
git log --merges --oneline --grep="feature/login"
如何还原某次合并时的实际冲突文件和修改行
查到合并提交哈希（比如 abc1234）后，不能直接用 git show abc1234 看冲突内容——那只是合并结果，不是冲突过程。要看「冲突发生时双方改了什么」，得对比两个父提交：
-
git diff abc1234^1 abc1234^2 -- path/to/file.js：显示两个分支在该文件上的全部差异（即冲突根源） -
git log --cherry-pick --oneline abc1234^1...abc1234^2：列出仅在第二个分支（通常是 feature 分支）里、但没在第一个分支（如 main）里的提交，这些就是可能引发冲突的改动来源
注意：abc1234^1 是当前分支（如 main）的最新提交，abc1234^2 是被合并进来的分支（如 feature）的 tip —— 顺序反了会得到空结果或误判。
Git Changelog Generator
下载
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
为什么 git blame 看不到冲突时的原始修改
git blame 显示的是「最终合并后文件每行的最后修改者」，它不保留冲突标记（如 <<<< HEAD）或被丢弃的版本。也就是说，一旦冲突解决并提交，那些未被采纳的修改就从文件内容里消失了，git blame 无法回溯。
想找回当时被舍弃的代码，唯一可靠方式是查另一个父提交：
- 如果最终保留的是
HEAD^1的逻辑，那被覆盖的改动就在HEAD^2对应的提交里 - 用
git show abc1234^2:path/to/file.js提取那个时刻的完整文件快照 - 再用
git log -p abc1234^2 -S"关键词"在该分支历史里搜具体变更
有没有办法自动标记或记录每次冲突
Git 本身不提供冲突日志功能。但你可以通过钩子（hook）或流程约定补上：
- 在
.git/hooks/post-merge里加脚本，检测git status --porcelain | grep "^UU"，有输出说明刚发生的 merge 含未解决冲突（但此时已失败，实际更常用pre-merge-commit） - 团队约定：所有手动解决冲突后，必须在提交信息里写明
Resolves conflict in: fileA, fileB，这样后续可用git log --grep="conflict"快速筛选 - CI 流水线中，在
merge步骤前运行git diff --name-only HEAD...MERGE_HEAD，把冲突文件列表存为 artifact
真正难的不是查某一次，而是查「谁在哪次合入时改了同一块逻辑」——这种交叉修改关系，靠单条命令很难闭环，得结合 git log -L 行范围追溯 + 分支图（git log --graph）一起看。
