git blame的方法的问题，但我不太了解它们。我在GitHub接口的文件顶部看到一个Blame按钮。单击它后，它在左侧栏上显示一些带有用户名的差异。这说明什么？
为什么除了GitHub之外，实际上还使用了
git blame？#1 楼
来自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 blame path/to/file中的每个提交运行git log。评论
所以只是为了看到最后一个人？
–Rıfat Erdem Sahin
18/12/2在17:44
是的，它使您可以看到更改线路的最后一个人。
–马克
19年2月8日在10:45
@Mark因此，当我们在IDE上进行注释时，它会在内部发出git blame命令？
– Nagarajan Shanmuganathan
19年7月24日在21:27
@NagarajanShanmuganathan是的，如果您使用git，那么这就是幕后发生的事情。
–马克
19年7月25日在9:35
#2 楼
该命令说明得很好。是要找出哪个同事写了特定行或破坏了项目，所以您可以责怪他们：)评论
该命令实际上听起来像是您将通过运行它来指责某人。至少在我了解这篇文章之前，这就是我的感受。
– Franccisco C.
17年6月9日在20:28
@FranciscoC。您正在寻找这个：github.com/jayphelps/git-blame-someone-else
–尘狼
18年4月25日在17:43
@FranciscoC。等待什么，难道不就是要让你责怪别人吗？
–IanDess
18-10-18在16:16
@IanDess也许仅仅是语义，但是git blame听起来好像会产生一些持久的效果，类似于git commit，实际上它只是告诉您由谁进行了哪些更改。 “责备”一词所带有的负面含义和含义使命令听起来像您应该远离的事物，并导致诸如此类的问题寻求澄清。
– Franccisco C.
18-10-18在19:37
显然，它应该被称为git赞许。
– pfnuesel
18/12/6在19:45
#3 楼
来自GitHub：blame命令是Git功能，旨在帮助您确定谁对文件进行了更改。
尽管它有负面影响听起来不错，git blame实际上很漂亮
无害；它的主要功能是指出谁更改了文件中的哪些行以及原因。它是识别代码中的更改的有用工具。
git-blame基本上用于显示文件的每一行的修订和作者最后一次修改。就像检查文件的开发历史一样。评论
这对我来说似乎是多余的，您可以从提交日志中看到用户与提交和ID之间的区别。如果我在这里了解所有内容，那么它的持久性就比提交历史要小。也许我缺少了一些东西，但是似乎是通过公开羞辱来实施编码标准。
–user1431356
18年2月15日在18:03
我想命令的名称是Linus特定幽默感的结果:)并不是用来羞辱任何人的:)它只是一个有趣的（或不）选择有用命令的名称。 :)
–满载B.
18年3月16日在12:29
@ user1431356-关键是您想要影响特定行的第一条日志行。否则，您需要在日志中搜索特定的字符串。 （这确实是一种可行的方法-在手册页中查找“ git log -S”。）
–azernik
18-4-4在22:49
“怪”标题是在git之前已经存在多年的东西。只是看svn的实现。它不是莱纳斯·托瓦尔兹（Linus Torvalds）的名字。
–JackAce
18年7月5日在17:07
“我想命令的名称是莱纳斯特定幽默感的结果：）并不是用来侮辱任何人：）”大声笑……更像是莱纳斯的个性，这意味着羞辱某人。
–感官
19 Mar 9 '19 at 23:37
#4 楼
git blame命令用于了解谁/哪个提交负责对文件进行的最新更改。还可以看到每一行的作者/提交。git blame filename（负责更改代码中的所有行）git blame filename -L 0,10（负责更改“ 0”行的内容“行到“ 10”行）还有很多其他的原因要怪，但是通常这些都可以帮上忙。
#5 楼
git blame命令使用最后一次修改该行的修订版中的信息对行进行注释，并且...使用Git 2.22（2019年第二季度）的速度更快，因为围绕“ git blame”进行了性能修复，尤其是在线性历史记录中（是我们应该优化的规范）。请参阅David Kastrup（
fedelibre）提交的f892014（02 Apr 2019）。（由Junio C Hamano合并-
gitster-在4d8c4da提交中，2019年4月25日）blame.c：不要像急切地丢弃原始Blob一样当父Blob已经有排队等待归类的块时，在一个归咎步骤的末尾丢弃Blob将会导致立即重新加载，在处理线性历史记录时将I / O数量加倍并拆包。
将此类父Blob保留在内存中似乎是一个合理的优化，主要应在处理来自以下位置的合并时产生额外的内存压力旧树枝。
#6 楼
git blame命令用于逐行检查文件的内容，并查看每行的最后修改时间以及修改的作者。如果存在错误，请执行以下操作。代码，使用它来识别是谁造成的，然后您可以责怪他。 Git的责任归咎于（d）。
如果您需要了解一个行代码的历史记录，请使用
git log -S"code here"，比git的责任更简单。git log vs git blame
评论
如果听起来也很“怪”，那么，请怪我，您可以安装此脚本并改用git赞赏:) github.com/ansman/git-praise它既不应该责备，也不应该赞美。它本质上是假设性的，应该是客观的。
gitobjective-determine-contributer只是没有相同的含义。
@RitwikBose或仅仅是git who
对于那些认为责备不佳的人，请回想一下git来自哪里