线上配置被改错，git log 只看到一堆提交标题，定位不到具体哪行。这时候在项目目录敲 git blame 文件名，每一行前面会带上提交哈希、作者、时间和行号，谁在哪个提交里动了这行，一眼能看到。这个命令只读历史，不改代码，放心跑。
输出大概是哈希前八位、作者名、日期、行号，末尾才是代码。终端里按 q 退出，别用 Ctrl+C 硬断。文件长的时候别全看，加 -L 指定范围，比如 git blame -L 40,60 app.js，只看第 40 到 60 行；文件改过名就加 --follow，不然历史会在改名处断掉。
几个常配的参数
- -L 起止行：只查一段，最常用
- -w：忽略空格改动，格式化提交不干扰
- -C：顺着复制粘贴找源头，能跨文件追
- --since=2024-01-01：只看某个时间之后的改动
看到可疑的行，拿哈希去 git show 看完整提交，再 git log -p 看上下文。只想看某个人，加 --author=名字，邮箱也能匹配，团队里重名时好用。VS Code 装个 GitLens，光标停在行上就显示作者，比命令行直观，但大仓库第一次索引会慢。
它只回答谁改的，不回答为什么
blame 记录的是最近一次修改这行的人，原始作者可能早被覆盖。重构、格式化、批量替换都会把名字换成执行操作的人，所以别拿它当问责工具。真要查原因，顺着提交信息、需求单和代码评审记录一起看。
团队协作时，文件名和路径要写全，只给个大概查不到，blame 之前先 git pull，不然本地历史落后，看到的作者和线上不一致。查大文件可以先用 --porcelain 输出机器可读的格式，再配合脚本筛作者和提交。遇到合并提交，行号可能指向合并点，顺着 git show 看两个父提交的差异更清楚。
日常用得最多的是排查回归：某行逻辑不对，先 git blame 找到提交，再看那次改动的 diff。老项目历史乱，结果可能指向一次大规模迁移提交，这种时候看 diff 比看作者有用。查完把结论写进工单，顺手把可疑提交的链接贴进去，下次别人不用再翻一遍。