git blame 是按行标注提交信息以快速定位代码修改源头的命令，需配合 -c -m 参数追踪拷贝与重命名，git annotate 仅为别名；查某行历史变化应使用 git log -l；gui 工具虽便捷但默认可能不启用重命名追踪。
git blame 看某行是谁在什么时候改的
想快速定位某一行代码的来龙去脉，git blame 是最直接的命令。它不是“查看历史修改记录”的泛泛工具，而是按行标注每次提交信息，适合排查 bug 源头或理解某段逻辑为何长这样。
常见错误是直接在项目根目录跑 git blame filename 却没注意当前分支——结果看到的提交可能来自已合并但未推送的本地分支，或者更糟：文件被重命名过，git blame 默认不追踪重命名，会断在 rename 前。
- 加
-C参数启用跨文件拷贝/移动检测（比如从utils.js拷贝函数到helpers.js） - 加
-M启用重命名检测（推荐组合：git blame -C -M filename） - 如果文件近期被大幅重构，单看最新 blame 容易误判；可配合
git log -p --follow filename查重命名链路 - 终端里默认只显示 commit hash 和作者，加
-l显示完整 hash，加--date short让时间更易读
git annotate 是 git blame 的别名，不是独立命令
git annotate 在 Git 1.8+ 就只是 git blame 的符号链接，行为完全一致，连参数都一模一样。文档里写它“更语义化”，实际没人维护单独逻辑——所以别搜“git annotate 教程”，所有资料都该查 git blame。
容易踩的坑是看到老博客或 Stack Overflow 回答里用 git annotate，就以为它支持额外功能。其实输入 git annotate --help 输出的也是 git blame 的帮助页。有些旧脚本里还留着这个命令，升级 Git 后照常运行，纯属兼容性保留。
- 别为
git annotate配置特殊 alias，它不会带来新能力 - CI 脚本里若用了
git annotate，建议统一替换成git blame，避免新人困惑 - Git for Windows 或某些精简发行版可能默认不带
git annotate符号链接，直接报 command not found —— 这时换git blame准没错
想看某行在多个版本中的变化？blame 不够用
git blame 只告诉你“这一行最后是谁改的”，不展示这行内容本身怎么变的。比如某行从 if (x > 0) 改成 if (x >= 0)，blame 只标出第二次提交，看不到中间 > 到 >= 的演变过程。
这时候得切到具体 commit，用 git show COMMIT:filename | sed -n 'LINENUMp' 手动比对，或者更靠谱地用 git log -L：
git log -L 42,42:src/main.py --oneline
这条命令会列出第 42 行在历次提交中内容的变化（Git 2.19+ 支持）。注意：-L 对二进制文件无效，且遇到大文件或高频率修改的行，性能明显下降。
-
-L参数格式是start,end:file，单行就写42,42，范围写10,15 - 如果文件路径含空格，
:file部分要用引号包裹，如git log -L 1,1:"my file.txt" - Windows 上 PowerShell 可能解析
-L失败，优先用 Git Bash 或 WSL
Web IDE 和 GUI 工具里的 blame 功能常被低估
VS Code、JetBrains 系列、GitHub/GitLab 网页端都内置 blame 视图，右键某行就能跳转到对应 commit。它们比命令行多一个关键能力：自动处理 submodule、lfs 文件和部分符号链接，而原生命令行 git blame 遇到这些会直接失败或显示空白。
但 GUI 的默认行为也有陷阱：GitHub 网页 blame 默认不开启 -C -M，重命名过的文件会显示“this line was added in this commit”而非真实源头；VS Code 的 GitLens 插件虽强，但若工作区启用了 multi-root，blame 可能错选仓库根目录。
- GitHub 上看 blame 时，点右上角「…」→「Blame options」勾选「Track renames」才等效于
git blame -M - VS Code 中确认状态栏右下角显示的是目标仓库，不是父工作区
- GitLab 的 blame 页面 URL 加
?line_mode=true可强制按行高亮，避免滚动时丢失上下文
blame 类操作真正的复杂点不在命令本身，而在 Git 如何定义“同一行”——换行符差异、缩进调整、模板字符串拼接都会让行号偏移，导致你盯着 A 行查半天，其实真正改动发生在 B 行。这时候与其反复试参数，不如先用 git diff -U0 看最近一次变更的原始 patch，确认行号是否可信。
