这是我过去30分钟的问题：我的一个文件中有一些更改消失了，我不知道发生了什么。我想知道是谁做的！
我开始寻找包含我的文件的修订版：
git grep <searched_string> $(git rev-list --all) -- <file>
是文件的路径或* .gsp
之类的通配符我得到了一些修改，我看了最后一个，并尝试得到它的孩子（认为第一个孩子应该是我的变化消失的第一个修订）
git rev-list --children <revision_id>
是从前一个命令的最后一行开始的40个字符
越来越近了！我正在查看输出的开头，然后选择第一个孩子，然后运行
git log <revision_id_s_first_child> --stat
然后我查看输出并找到我的文件以及谁做了更改！ （原来，我应该责怪......）
有没有更快地做到这一点（git blame不会显示已被删除的内容）？
答案 0 :(得分：27)
git blame有一个--reverse选项，它接受一系列提交，并向您显示删除之前存在一行的最后一次提交。所以，你发现一个提交，你知道线条在那里，比如说abcdef01，并在删除前显示最后一次提交，执行：
git blame --reverse abcdef01..HEAD -- <file>
答案 1 :(得分：9)
如果您知道某些子字符串将在已删除的行中，那么您可以使用-G选项git log来查找引入了添加或删除包含该子字符串的行的更改的提交。例如如果你知道“大流行”这个词在消失的那一行，你可以这样做：
git log -Gpandemic -p
（-G的参数可以是正则表达式。）这个选项最近添加到git中 - 如果它不起作用，请尝试使用-S，它的语义略有不同，但是应该有类似的效果。
答案 2 :(得分：3)
请注意，自Git 2.11（2016年第4季度）以来，如果您想查看特定的提交和当前之间的提交，则不必指定..HEAD。
因此，Karl Bielefeldt＆＃39; s answer将成为：
git blame --reverse abcdef01 -- <file>
commit d993ce1见Junio C Hamano (gitster)（2016年6月14日）
（Junio C Hamano -- gitster --于2016年10月10日commit 1172e16合并）
责备：dwim＆＃34;
blame --reverse OLD＆＃34; as＆＃34;blame --reverse OLD..＆＃34;说＆＃34;
git blame --reverse OLD path＆＃34;是一个常见的错误，期望命令行被打开，好像询问旧版本OLD中的路径中的行是如何存活到当前提交的而不是总是要求范围的两端，我们可以DWIM＆＃34;
OLD＆＃34;，这可能是拼写错误＆＃34;OLD..＆＃34;，是一个以当前提交结束的范围。
git blame --reverse现在包括：
--reverse <rev>..<rev>:
向前走，而不是向后走 这显示了一条线存在的最后一个修订版，而不是显示一行出现的修订版 这需要一系列修订，例如
START..END，其中指责的路径存在于START中 为方便起见，git blame --reverse START被视为git blame --reverse START..HEAD。
（注意事项："dwim" is an acronym for "Do What I Mean" (not what I say)）
答案 3 :(得分：1)
git blame --reverse 可以让您接近删除行的位置。但它实际上并没有指向删除行的修订版。它指向最后修订，其中该行存在。然后，如果以下版本是普通提交，那么您很幸运，并且您获得了删除修订版。 OTOH，如果以下修订版是合并提交，那么事情就会变得有点疯狂。作为创建 difflame 的努力的一部分，我解决了这个问题，所以如果你已经在你的盒子上安装了python并且你愿意尝试一下，那就不要再等了。让我知道它是怎么回事。