查看 Git 文件的历史修改记录主要使用 git log 命令，而定位每一行代码的责任人则需要 git blame 命令，两者配合才能完整还原文件的变更脉络。
先说结论：git log 负责文件级的提交历史，git blame 负责行级的最后修改者，重命名文件需加特定参数追踪。
- 适合：需要追溯代码变更来源、排查 Bug 责任人或审计文件变动场景。
- 先看：确认文件路径是否正确，以及文件是否经历过重命名。
- 建议：结合 git log -L 查看特定行的演变过程，避免 blame 信息单一。
命令速用版
# 查看文件提交历史（含差异，追踪重命名）
git log `--follow` -p -- 文件路径
# 查看每一行的最后修改者（追踪重命名和拷贝）
# 注意：-C 参数在大文件上可能较慢
git blame -C -M 文件路径
# 查看特定行的历史演变（Git 2.19+）
# 注意使用英文逗号和冒号
git log -L 起始行，结束行：文件路径原理简述
Git 的历史记录本质上是提交（commit）的链表，文件只是提交中的快照。git log 是按提交维度展示哪些 commit 动过这个文件，而 git blame 是按行维度展示当前文件每一行最后一次出现在哪个 commit 里。很多人混淆两者，以为 blame 能看到某行代码的所有历史修改，其实它只显示“最后一手”，中间被覆盖的修改记录需要靠 git log -L 来回溯。
分步处理
1. 确认文件路径
确保路径是相对于工作目录的。在 Windows 的 Git Bash 或 Linux/Mac 终端中，建议使用正斜杠 /（例如 src/utils.js），即使是在 Windows 系统下，Git 命令通常也兼容正斜杠，避免反斜杠 \ 导致的转义问题。
2. 查看文件级历史
运行 git log `--follow` -p -- 文件路径。`--follow` 参数至关重要，它能追踪文件重命名前的历史，否则文件改名后的早期记录会断开。
3. 查看行级责任人
运行 git blame -C -M 文件路径。-C 检测跨文件拷贝，-M 检测重命名，这样能避免因为代码复制粘贴而误判作者。如果需要更清晰的时间格式，可加 `--date` short。
4. 追踪特定行演变
如果发现某行逻辑可疑，用 git log -L 42,42:文件路径 查看第 42 行在所有提交中的变化。这能弥补 blame 只能看最后一次修改的不足。
怎么验证是否生效
执行命令后，检查终端输出是否包含预期的 commit hash、作者邮箱和时间。对于 git log，确认能看到文件重命名前的提交记录；对于 git blame，确认每行代码前都有标注信息。如果输出为空，检查当前分支是否包含该文件，或路径是否拼写错误。
常见坑与性能注意
1. 命令中的符号错误
复制命令时切勿包含反引号（`），例如 `--follow` 周围不应有反引号，否则 shell 会尝试执行命令替换导致错误。git log -L 参数中的逗号和冒号必须是英文符号，中文标点会导致命令无法识别。
2. 重命名导致历史断裂
默认 git log 不追踪重命名，必须加 `--follow`。git blame 默认也不追踪，需加 -M -C 参数，否则改名后的文件会丢失早期作者信息。
3. 中文路径乱码
在 Git Bash 或某些终端，中文路径可能显示为八进制转义字符。可运行 git config `--global` core.quotepath false 解决。
4. 性能影响
git blame -C 会检测代码拷贝，涉及大量文件比对，在大型仓库或大文件上执行可能较慢，必要时可省略 -C 仅使用 -M。
5. blame 不是全历史
git blame 只显示当前内容的直接来源，如果某行被多次修改，它只标最后一次。不要用它统计“改过几次”，那是 git log 的工作。