git blame 直接显示文件每行的最近修改者，如 git blame src/utils.js 查第42行作者；未提交改动需用 --cached，合并引入的代码应结合 git log -s 和 git blame ^ 追溯原始作者。

git blame 怎么看某行是谁写的

直接用 git blame，它就是干这个的。不是查日志，也不是翻 commit 记录，而是把文件每一行映射到最近一次修改它的 commit 和作者。

最常用命令：git blame <file></file>。比如想查 src/utils.js 第 42 行，就运行：

git blame src/utils.js

输出里每行开头会显示 commit hash、作者名、时间、行号——第 42 行对应哪一行输出，作者就写在那行里。

• 如果文件很大，加 -L 精确到行范围，比如只看 42–45 行：git blame -L 42,45 src/utils.js
• 加 -e 显示完整邮箱，避免昵称冲突：git blame -e src/utils.js
• 加 --show-name 防止重命名导致路径不一致时看错文件

git blame 查不到最新修改？可能是暂存区或工作区改动

git blame 默认只看已提交的历史。如果你刚改完还没 git add，或者改了但没 commit，它不会显示你——它看到的还是上一个 commit 的状态。

GitHub Hosts CN

GitHub Hosts 更新工具（仅限中国用户），安全更新系统hosts文件，保留原有非GitHub条目，仅替换GitHub相关地址。支持备份恢复和风险提示。用于解决GitHub访问问题。

下载

• 确认是否已 commit：git status 看有没有未提交变更
• 想包含暂存区（staged）改动，加 --cached 参数：git blame --cached src/utils.js
• 但注意：--cached 只对已 git add 的文件生效；纯工作区（unstaged）改动仍不可见
• 常见误判：看到“作者 A”，结果发现是 A 之前 merge 进来的分支，实际写代码的是 B ——这时得用 git show <commit-hash></commit-hash> 往上翻原始 commit

git blame 跳过合并提交，怎么追到真正作者

默认情况下，git blame 遇到 merge commit 会停住，不继续往父提交追溯。所以如果某行是通过 merge 引入的，你看到的可能是 merge 提交的作者，而不是原始作者。

• 加 -M 启用重命名/移动检测（对跨文件搬代码有用）
• 关键参数是 -c（cherry-pick 模式）或更实用的 --ancestry-path + 手动指定起始 commit
• 更直接的办法：先用 git log -p -S "关键词" -- <file></file> 定位引入该行的 commit，再用 git blame <commit-hash>^ -- <file></file></commit-hash> 往前查父提交
• 别依赖 IDE 内置的 blame 功能——很多编辑器默认关掉了 -c 和 -M，查出来的作者容易错

blame 结果里作者名乱码或显示不全

通常是 Git 配置的 user.name 编码问题，或者历史 commit 用了非 UTF-8 字符集提交。

• 检查当前配置：git config --get user.name，确认是否含中文且编码正常
• 临时让 blame 强制用 UTF-8：GIT_COMMITTER_NAME='中文名' git blame src/utils.js
• 历史乱码无法修复，但可用 --date=iso 或 --abbrev=8 减少干扰信息，聚焦 author 和 hash
• 团队协作中，建议统一设置：git config --global core.precomposeUnicode true（macOS）或 git config --global i18n.commitencoding UTF-8

真正难的不是命令怎么敲，而是看到作者名后，还得判断那行代码是不是他写的逻辑、还是只是顺手格式化了一下。blame 给的是“最后触碰者”，不是“责任归属”。