从git-blame:

用上次修改该行的修订中的信息注释给定文件中的每一行。可以选择从给定的修订开始注释。 当指定一次或多次时，-L将注释限制为所请求的行。

例子:

johndoe@server.com:~# git blame .htaccess
...
^e1fb2d7 (John Doe 2015-07-03 06:30:25 -0300  4) allow from all
^72fgsdl (Arthur King 2015-07-03 06:34:12 -0300  5)
^e1fb2d7 (John Doe 2015-07-03 06:30:25 -0300  6) <IfModule mod_rewrite.c>
^72fgsdl (Arthur King 2015-07-03 06:34:12 -0300  7)     RewriteEngine On
...

请注意，git blame没有按时间顺序显示每行修改历史。 它只显示在HEAD中最后一次提交之前，谁是最后一个更改文档中的一行的人。

也就是说，为了查看文档行的完整历史/日志，您需要为git日志中的每次提交运行git blame path/to/file。

从GitHub:

blame命令是Git的一个特性，旨在帮助您确定是谁 对文件进行了更改。 尽管它的名字听起来很消极，但git blame实际上很漂亮 无害的;它的主要功能是指出谁改变了什么 文件中的行，以及原因。它可以是识别变化的有用工具 在你的代码中。

基本上，git-blame用于显示最后修改文件每一行的修订版本和作者。这就像检查一个文件的开发历史。

git blame命令用于逐行检查文件的内容，查看每一行最后修改的时间以及修改的作者是谁。

如果代码中有bug，用它来确定是谁发现了它，然后你就可以责怪他了。不被指责就是被指责(d)。

如果你需要知道一行代码的历史，使用git log -S"code here"。这比指责懦夫简单多了。

Git日志vs Git责备

git blame命令用上次修改该行的修订版本中的信息注释该行，并且…Git 2.22(2019年第二季度)会更快，因为围绕“Git责备”进行了性能修复，特别是在线性历史中(这是我们应该优化的标准)。

参见David Kastrup (fedelibre)的commit f892014(2019年4月2日)。 (由Junio C Hamano—gitster—在commit 4d8c4da中合并，2019年4月25日)

c:不要那么急切地丢掉原点的斑点 当父blob已经有块排队等待责备时，在一个责备步骤结束时丢弃blob将导致它立即被重新加载，使I/O数量增加一倍，并在处理线性历史记录时解包。 在内存中保留这样的父blob似乎是一种合理的优化，但在处理来自旧分支的合并时，主要会产生额外的内存压力。

从git-blame:

用上次修改该行的修订中的信息注释给定文件中的每一行。可以选择从给定的修订开始注释。 当指定一次或多次时，-L将注释限制为所请求的行。

例子:

johndoe@server.com:~# git blame .htaccess
...
^e1fb2d7 (John Doe 2015-07-03 06:30:25 -0300  4) allow from all
^72fgsdl (Arthur King 2015-07-03 06:34:12 -0300  5)
^e1fb2d7 (John Doe 2015-07-03 06:30:25 -0300  6) <IfModule mod_rewrite.c>
^72fgsdl (Arthur King 2015-07-03 06:34:12 -0300  7)     RewriteEngine On
...

请注意，git blame没有按时间顺序显示每行修改历史。 它只显示在HEAD中最后一次提交之前，谁是最后一个更改文档中的一行的人。

也就是说，为了查看文档行的完整历史/日志，您需要为git日志中的每次提交运行git blame path/to/file。

这是为了找出是哪个同事写了这句话，或者是哪个同事毁了这个项目，这样你就可以责怪他们了:)