git blame定位的是每行代码最后一次修改者而非最初作者；支持-L指定行、-C/-M追踪重命名、-p查看补丁等，但结果受提交规范影响。
git blame 查看某行代码是谁写的
直接用 git blame 就能定位到每一行的最后修改者，不是“最初作者”，而是“最后一次改这行的人”。这是它最常被误解的地方——很多人以为它能查“谁写了第一版”，其实它只追踪最近一次提交中该行的归属。
实操建议：
- 在项目根目录或目标文件所在目录运行：
git blame <filename></filename>，比如git blame src/utils.js - 想看具体某几行？加
-L参数：git blame -L 42,42 src/utils.js（只看第 42 行） - 加
-e显示完整邮箱，-w忽略空格变更，避免因格式调整误判作者 - 终端里按
q退出（别卡住以为没反应）
git blame 显示 commit ID 但看不到上下文
默认输出只有哈希、作者、时间、行号和代码，不带提交信息。光看 ID 很难判断这次修改到底干了啥，尤其遇到模糊的提交标题时。
实操建议：
- 加
-s精简模式（去掉时间戳），再配合-p输出完整 patch：git blame -sp src/api.ts - 更实用的是用
--show-name和--show-email确保字段不被截断 - 如果想顺手打开对应 commit，复制 ID 后执行：
git show <commit-hash></commit-hash>或git log -p -1 <commit-hash></commit-hash>
git blame 跨文件重命名/移动后结果不准
当文件被 git mv 或重命名后，git blame 默认不会追溯历史文件名，导致某行“凭空出现”，看起来像新写的——其实只是从 old.js 搬过来的。
实操建议：
- 必须加
-C（大写 C）启用跨文件拷贝检测：git blame -C -C src/newfile.ts（连用两个-C效果更好） - 加
-M启用重命名检测，适合重构场景：git blame -C -M -C src/index.ts - 注意：这些选项会明显变慢，尤其大仓库，别在 CI 脚本里无脑加
IDE 里点来点去不如命令行准确
VS Code、JetBrains 等 IDE 的 blame 插件看着方便，但底层调用的往往不是完整参数的 git blame，比如默认不带 -C/-M，也不支持 -L 定行，甚至缓存旧结果不刷新。
实操建议：
- 怀疑 IDE 显示有误？立刻切终端，用带
-C -M -L的完整命令交叉验证 - 某些 IDE（如 VS Code）的右键菜单“Blame”实际调用的是
git blame --porcelain，输出是机器解析格式，人眼难读，别依赖它做判断 - 团队内统一用命令行查责，比截图发群里问“这行谁动的”靠谱得多
blame 不是万能的，它只反映 Git 记录里的最后归属；如果有人 git commit --amend 后强制推送，或者多人共用一个账号提交，结果就完全失真。查之前先确认仓库提交规范有没有漏洞。
