1. 命令概述

git blame 的核心功能是 逐行追溯一个文件中每一行的最后修改信息。它可以告诉你：

• 谁 修改了这一行（作者）。
• 在哪个提交 中修改的（提交哈希）。
• 什么时候 修改的（提交时间）。
• 提交信息 是什么（可选）。

简单来说，它就是代码的“问责”工具，常用于：

• 定位引入 Bug 的特定提交。
• 了解某段代码的演变历史和上下文。
• 在代码审查时，了解特定变更的负责人。

2. 命令格式

基本的命令格式如下：

git blame [选项] <文件名>

如果要查看文件在某个特定修订版本（commit, branch, tag）中的状态，格式为：

git blame [选项] <修订版本> [--] <文件名>

• <修订版本>： 可以是提交哈希、分支名、标签名等。如果省略，则默认为 HEAD（当前最新版本）。
• [--]： 用于明确分隔修订版本和文件名，在文件名与修订版本名称可能混淆时使用（例如，文件名叫 main）。

3. 基本用法

假设我们有一个文件 example.py，我们想查看它的逐行修改记录。

git blame example.py

输出结果类似于：

^a1b2c3d (张三 2023-10-25 14:30:22 +0800 1) import os
^a1b2c3d (张三 2023-10-25 14:30:22 +0800 2) 
f4e5g6h7 (李四 2023-11-10 16:45:01 +0800 3) def calculate_sum(a, b):
f4e5g6h7 (李四 2023-11-10 16:45:01 +0800 4)     return a + b
i8j9k0l1 (王五 2023-12-01 11:20:15 +0800 5) def calculate_product(a, b):
i8j9k0l1 (王五 2023-12-01 11:20:15 +0800 6)     # 修复了乘法逻辑 (Bug #123)
i8j9k0l1 (王五 2023-12-01 11:20:15 +0800 7)     return a * b

输出列解析：

1. 提交哈希（Commit Hash）： 例如 f4e5g6h7，是该行代码的最后修改提交的唯一标识。开头的 ^ 符号表示该行来自文件的初始提交。
2. 作者（Author）： 修改这行代码的人。
3. 时间戳（Timestamp）： 提交创建的时间。
4. 行号（Line Number）： 该行在文件中的当前行号。
5. 代码内容（Code Content）： 该行的实际代码。

4. 高级用法

git blame 的强大之处在于其丰富的选项，可以应对各种复杂场景。

4.1 追踪代码移动 (-C, -M)

当代码在文件内或文件间被移动或复制时，默认的 blame 只会追踪到最后一次修改内容（而不是移动）的提交。这些选项可以智能地追踪代码的起源。

• -C： 在同一个文件内查找代码移动的原始出处。*
• -C -C 或 -C： 额外在跨文件之间查找代码移动的原始出处。
• -M： 检测同一文件内移动或复制的代码行。
• 示例：

# 追踪example.py中代码的移动和复制，包括跨文件的
git blame -C -C -M example.py

这在重构后查找代码原始作者时极其有用。

4.2 限制追溯范围 (-L)

如果你只关心文件的某一部分，可以使用 -L 选项来指定行范围。示例：

# 只查看第10到第20行
git blame -L 10,20 example.py

# 查看从第15行到文件末尾
git blame -L 15, example.py

# 查看从匹配 “function_name” 的行开始，往后10行
git blame -L “/function_name/”,+10 example.py

4.3 忽略空格修改 (-w)

忽略由于空格（空格、制表符等）变化而产生的提交，只关注有实际内容变化的提交。这可以避免因单纯的格式化调整而干扰追溯结果。

git blame -w example.py

4.4 显示邮件地址 (-e)

在输出中显示作者的电子邮件地址，而不是用户名。

git blame -e example.py

输出：(zhangsan@email.com 2023-10-25 …)`

4.5 显示长格式信息 (-l)

显示完整的提交哈希（40位），而不是缩写形式。

git blame -l example.py

4.6 显示提交摘要行 (-s)

隐藏作者和时间信息，只显示提交哈希和代码内容，使输出更紧凑。

git blame -s example.py

输出：f4e5g6h7 3) def calculate_sum(a, b):

4.7 追溯特定修订版本

查看文件在历史某个节点时的状态。

# 追溯在 v1.0 标签时的文件状态
git blame v1.0 -- example.py

# 追溯在某个特定分支（如develop）上的文件状态
git blame develop -- example.py

# 追溯某个特定提交（如abc123）之前的文件状态

git blame abc123^ -- example.py

5. 注意事项

1. 不是真正的“责备”： 这个命令的名字带有负面含义，但在团队协作中，应将其视为一个 历史调查和学习的工具，而不是指责他人的武器。它的目的是找出“为什么”代码会变成这样，而不是“谁搞砸了”。

2. 二进制文件： git blame 对二进制文件无效，输出没有意义。

3. 移动/重命名文件的处理： Git 需要配置才能正确跟踪文件重命名。使用 git blame 时，如果文件被重命名过，你可能需要额外的选项（如 -C -C）或在追溯时指定旧的文件名。

4. 性能： 对于非常大的文件或历史非常长的仓库，git blame 可能会稍慢。使用 -L 限制范围可以提高速度。

6. 补充信息

6.1 图形化界面工具

虽然命令行功能强大，但图形化工具能更直观地展示 blame 信息。

• git gui blame <文件名>： Git 自带的图形化 blame 工具，交互性更好。
• IDE/编辑器集成： VS Code, IntelliJ IDEA, Sublime Text 等现代编辑器都内置了优秀的 blame 功能（通常叫 “Annotate” 或 “GitLens”），可以直接在代码行旁边看到提交信息，点击即可查看详情。

6.2 结合 git log 进行深入分析

git blame 帮你找到了引入变更的提交，接下来你可以用 git show <commit_hash> 或 git log -p <commit_hash> 来查看该提交的完整详细信息，包括具体修改了哪些代码以及提交信息。

工作流示例：

1. 用 git blame 找到导致问题的可疑行及其提交哈希（如 a1b2c3d）。

2. 用 git show a1b2c3d 查看那次提交的完整 diff 和日志，理解修改的上下文。

6.3 别名配置

由于一些选项组合很常用，可以为它们设置 Git 别名，提升效率。

# 创建一个能追踪代码移动和忽略空格的blame别名
git config --global alias.blame-w ‘blame -w -C -C’
# 之后就可以简单地使用
git blame-w example.py