git blame显示的不是你改的那一行，因其默认按当前文件最终状态逐行追溯最近一次修改该行的提交，而非按特定变更过滤；重构移动代码、rebase或cherry-pick会导致原始哈希失效，blame回退至更早提交。
git blame 为什么显示的不是你改的那一行
因为 git blame 默认按「当前文件最终状态」逐行追溯最近一次修改该行的提交，而不是按你关心的某次变更来过滤。如果你在重构后移动了大段代码，或执行了 git rebase、git cherry-pick，原始提交哈希可能已失效，blame 会回退到更早的、看似无关的提交。
实操建议：
- 用
-L精确指定行号范围，比如git blame -L 42,45 path/to/file.js，避免整文件扫描干扰 - 加
-w忽略空白差异，防止因缩进/换行改动导致 blame 跳变 - 配合
--ignore-revs-file（Git 2.23+）排除自动格式化提交，例如把 Prettier 提交哈希写入.git-blame-ignore-revs
如何查某次 PR 引入的某行代码现在归属谁
先定位 PR 对应的合并提交（git log --oneline --grep="PR #123"），再用 git blame 的 -S 参数从该提交开始反向追溯： git blame -S abc123f path/to/file.py。这会让 blame 从 abc123f 开始往回找，而非从 HEAD 往前推，更接近“那次变更的后续演化路径”。
注意点：
-
-S后跟的必须是存在且可到达的提交（不能是已 squash 的旧 commit） - 如果该行在
abc123f之后被重写过（如git filter-repo清洗历史），-S会失败并报错fatal: invalid revision - 想看完整上下文，加
-p输出原始 patch，方便比对 diff 是否真由该提交引入
blame 结果里作者和提交者不一致怎么办
常见于他人 git commit --author 代提交、CI 自动提交、或 git am 应用邮件补丁——此时 git blame 显示的是 author（真正写代码的人），但 git show 看到的是 committer（执行 commit 命令的人）。这不是 bug，是 Git 的设计逻辑。
若需统一查看，可用：
-
git blame --show-email确保邮箱字段不被截断 -
git log --pretty=format:"%h %an %cn " -n 1 <commit-hash>对比 author/committer 信息 - 团队内约定用
git config --global user.name和user.email统一 author 信息，避免 CI 提交混入个人邮箱
大仓库中 git blame 卡住或超时
本质是 Git 需遍历历史构建行级溯源图，文件越大、历史越长，耗时指数上升。尤其当文件被多次 rename 或 copy，Git 会尝试跨重命名追踪，开销极大。
提速关键：
- 用
--follow仅在确认有重命名时才加，否则默认关闭（Git 2.29+ 默认禁用） - 限制追溯深度：
git blame -n 100只往前查最多 100 次提交，适合快速定位近期变更 - 预热索引：
git config --global blame.ignorecase true减少大小写敏感比对；搭配git update-index --skip-worktree冻结不常改的大文件
真正难搞的是二进制文件或自动生成代码（如 protobuf 编译产物）——git blame 对它们无意义，应从 .gitattributes 中用 *.pb.go -diff 明确排除。
