git blame 可定位具体修改人但需先手动确定冲突行号，git log -s 适合按代码内容溯源，而 git diff --cc 等命令不显示作者信息，需结合提交历史与 pr 上下文才能真正解决冲突。
git blame 能定位到具体修改人，但得先知道哪行有冲突
冲突发生后，git status 只告诉你哪些文件冲突了，不会直接标出“第17行是张三改的、第18行是李四改的”。想查清楚是谁在什么时候改了冲突位置，得靠 git blame 配合手动定位。它不是自动扫描冲突块，而是对**已知行号**做追溯——所以你得先打开冲突文件，找到 和 <code>>>>>>> branch-name 之间的具体行，再对那一行运行命令。
- 用
git status确认冲突文件，比如src/utils.js - 用编辑器打开该文件，找到冲突段落，记下你想查的行号（例如第42行）
- 执行
git blame -L 42,42 src/utils.js，输出会显示该行最后一次提交的哈希、作者、时间、提交信息 - 如果冲突涉及多行，可扩大范围，如
-L 40,45；加-w忽略空白差异，避免因格式改动干扰判断
冲突区域太大时，git log -S 是更高效的溯源方式
当冲突块较长、或你不确定具体哪一行关键，git blame 逐行查太慢。git log -S 能按“代码内容变化”反向搜索：它找出所有**引入或删除了某段字符串**的提交。这对函数签名变更、常量重命名、API 调用替换这类典型冲突特别有用。
- 从冲突段中提取一个稳定、唯一的字符串，比如
calculateTotal(items, taxRate) - 执行
git log -S "calculateTotal(items, taxRate)" --oneline -- src/utils.js - 结果会列出所有修改过该字符串的提交，结合作者和提交信息，基本能锁定谁在哪个分支动了这部分
- 注意：-S 匹配的是“完整字符串的增删”，不是模糊搜索；若字符串含变量名或空格易变，换成更稳定的标识，如函数名
calculateTotal即可
别依赖 git diff --cc 显示作者，它根本不显示
git diff --cc 或 git show :2:file 这类命令能帮你看到冲突三方（base / ours / theirs）的内容，但它们**不包含作者信息**。很多人误以为 “既然能看到三个版本，那肯定能知道谁写的”，其实 Git 在内部对象层面就只存提交哈希，不把作者附在 blob 上。想确认作者，必须回到提交历史层，也就是 git blame 或 git log。
- 运行
git diff --cc src/utils.js只会显示冲突块的合并视图，没有 author 字段 - 想看某次提交是谁写的，得先用
git log --oneline src/utils.js找出相关提交，再用git show <commit-hash></commit-hash>查 author - VS Code 内置的冲突编辑器右侧会显示“Incoming Change”来自哪个分支，但也不会显示具体作者——这是 IDE 的限制，不是 Git 的能力边界
多人协作中真正容易被忽略的点
查作者只是第一步，真正卡住人的往往是上下文缺失：你看到“张三改了这行”，但不知道他为什么加 taxRate 参数，也不知道李四删掉它的理由。Git 不记录意图，只记录动作。所以最有效的做法不是单查作者，而是把 git blame 输出的提交哈希粘贴进 PR 或 commit 页面，直接跳转到那次变更的完整 diff 和评论区——那里往往有设计讨论、Jira 链接、甚至截图。没有上下文的“谁改的”，解决不了冲突，只会让你更困惑。
