git blame 默认不准，因只显示已提交历史、遇 merge 停止追踪、重命名不识别；需用 --ancestry-path、-c-m、-s、--ignore-rev 等参数及交叉验证确保作者可信。
直接用 git blame 就能显示每行最近修改者，但默认输出信息少、易误判、对重命名/合并不敏感——关键不是“能不能看”，而是“看到的是否可信”。
git blame 基础命令为什么常不准
默认只显示已提交历史，工作区或暂存区改动完全不可见；遇到 merge 提交就停住，把 merge 者当成作者，实际代码可能是别人写的；文件重命名后不加参数，会把整块复制的代码标成“新写”。
- 运行
git status确认目标行是否已 commit：未git add或未git commit的改动，git blame一律无视 - 看到作者是“张三”，但他是 merge 者？加
--ancestry-path并手动查父提交：git blame abc123^ -- file.js - 文件刚被重命名（如
utils.js → helpers.js）？必须加-C -M，否则所有行都显示为“张三 5 分钟前”——其实是李四三年前写的 - 终端里作者名乱码？检查
git config --get user.name，非 UTF-8 提交需临时设环境变量：GIT_COMMITTER_NAME='中文名' git blame file.js
怎么让 git blame 显示完整邮箱和标准时间
默认只显示昵称和 Unix 时间戳，多人同名或跨时区协作时极易混淆。用 --format 自定义输出最可靠，比零散参数组合更可控。
- 显示完整邮箱 + ISO 时间 + 精简哈希：
git blame --format="%an %aI %h" src/index.js - VS Code 中想全局生效？改设置项
git.blame.format，值设为"%an %aI %h"（注意英文引号包裹） - 时间用
%aI不用%ad：前者是 author date（真实提交时间），后者可能被--amend或 rebase 修改过 - 大文件（>3k 行）开启详细格式会卡顿 1–2 秒，建议仅调试时用，日常保持默认
如何追溯某行“最初是谁写的”，而不是“最后谁改的”
git blame 只回答“最后一笔”，要查“第一笔”得切到 git log -S —— 它搜的是 diff 内容变化，不是行号。
- 找某行文本首次出现：先复制那行代码（如
if (status === 'active')），再执行git log -S "if (status === 'active')" --oneline -- src/api.js - 结果里最早的 commit 就是引入者；如果返回空，说明该行被格式化/生成器重写过，原始提交已不可见
- 配合
-p看上下文：git log -S "xxx" -p -1 src/file.js，确认是不是真新增，还是只是替换 - 别信 IDE 的 “Show Line History”：VS Code 和 IntelliJ 默认调用的是
git log -L（查行级变更链），不是git log -S（查首次引入），二者语义完全不同
跳过特定提交（比如自动格式化、CI 注入）
一次 Prettier 全量格式化可能让所有行的 blame 指向同一个 commit，掩盖真实作者。Git 支持显式忽略这些“噪音提交”。
- 建文件
.git-blame-ignore-revs，每行一个要忽略的 commit hash：echo "a1b2c3d" >> .git-blame-ignore-revs - 启用忽略机制：
git config blame.ignoreRevsFile .git-blame-ignore-revs - 验证是否生效：
git blame --ignore-rev a1b2c3d src/file.js（单次忽略） - 注意：被忽略的提交若修改了多行，其后的修改会被归到更早的提交上，可能导致作者错位——所以只忽略明确无业务逻辑的提交
真正难的不是命令怎么敲，而是看到“张三”之后，得判断这行代码是张三写的、张三 merge 进来的、张三格式化过的，还是张三从另一个文件 copy 过来的——git blame 输出本身不带这个元信息，得靠 -C、-M、-S 和人工交叉验证。
