Git：查找已删除的代码

这让我发疯。

如何查找已删除的代码？

我最终找到了它的创建位置：

$ git log --pretty=oneline -S'some code'

这就足够了，但是我也很想知道它被删除的位置，到目前为止，还没有骰子。

首先，我尝试git diff HEAD..HEAD^|grep 'some code'每次都扩大范围，直到找到将其删除的行。很好，所以假设我在range上找到了它HEAD^^..HEAD^^^，然后git show HEAD^^^与git show HEAD^^一起使用grep，但是找不到代码了！

然后我继续阅读git bisect，果然，它给了我一个罪魁祸首应该是的修订版...再一次，git show rev|grep 'some code'空了...

什么啊 我究竟做错了什么？

谢谢！

汉弗，为我工作：

$ git init
在/Users/pknotz/foo/.git/中初始化了空的Git存储库

$ echo“你好”> a

$ git添加一个

$ git commit -am“初始提交”
[master（root-commit）7e52a51]初始提交
 更改1个文件，1个插入（+），0个删除（-）
 创建模式100644 a

$ echo“世界” >>一个

$ git commit -am“更具体”
[master 080e9fe]更具体
 更改1个文件，1个插入（+），0个删除（-）

$ echo“你好”> a

$ git commit -am“不太具体”
[master 00f3fd0]不太具体
 更改1个文件，0个插入（+），1个删除（-）

$猫一个
你好

$ git log -SWorld
提交00f3fd0134d0d54aafbb9d959666efc5fd492b4f
作者：Pat Notz <patnotz@gmail.com>
日期：2009年10月6日星期二17:20:48 2009-0600

    不太具体

提交080e9fe84ff89aab9d9d51fb5d8d59e8f663ee7f
作者：Pat Notz <patnotz@gmail.com>
日期：2009年10月6日星期二17:20:33 2009-0600

    更加详细一些

或者，这不是您的意思吗？

git log -S<string>做这项工作，但是如果您需要进行更复杂的搜索，则可以使用git log -G<regex>。

来自man：

-G<regex>

寻找差异，其补丁文本包含匹配的已添加/已删除的行<regex>。

自己开车疯时发现了您的问题，到目前为止，还没有答案是足够的。我找到了一种找到特定提交的方法，但是仅在这些提交之间进行区分时才会显示。我无法解释为什么git这样工作，但是我将详细说明我的发现：

问题解释

使用“ -S”或“ -G”，我们只能找到它的添加位置，而不能删除。详细说明：

$ git log --format="%H" -S"127.0.124.1"
857aa361293abbb351d6d6becaa55ec011aebc93
$ git show 857aa361293abbb351d6d6becaa55ec011aebc93 | grep "127.0.124.1" # remove grep to see full diff
+       return "127.0.124.1", nil

一步步

我从dev.to上的miku86那里得到了这个主意。首先，我们尝试找到存在我们字符串的最后一个提交：

$ git --no-pager grep "127.0.124.1" $(git rev-list --all) # | head -n1 | cut -d: -f1 # uncomment to only show the hash of the first one
ba0b2d348f4e33857c96acf5a6231cf9d89ddb1b:some/file.go:        return "127.0.124.1"
0d19a98d6434da0b4b5cc2bac190b9b1de36d992:some/file.go:        return "127.0.124.1"
84274c5712bacbbee1dca5567cef77a2b6f356d2:some/file.go:        return "127.0.124.1"
42e692643ff8a5dce7a89e985062b3d38c60fcc0:some/file.go:        return "127.0.124.1"

结果ba0b2d348f4e33857c96acf5a6231cf9d89ddb1b是我们搜索到的提交。接下来，我们尝试查找在这之后直到HEAD的提交：

$ git rev-list ba0b2d348f4e33857c96acf5a6231cf9d89ddb1b.. # | tail -n1 # uncomment to only show the last one
[...]
c82d040f7be2f8955075655843400a36ceb75303
aa0568b543db57564770d73e736aaf50fd749fb4
dde61dae0cf648e7f4dd8a5c194bcf9be1745793

这是dde61dae0cf648e7f4dd8a5c194bcf9be1745793，因为这是我们要查找的列表中的最后一个。

因此，这意味着dde61dae0cf648e7f4dd8a5c194bcf9be1745793应包括该清除？

$ git show dde61dae0cf648e7f4dd8a5c194bcf9be1745793 | grep "127.0.124.1" # remove grep to see full diff
#<no output>

没有？！？那么从那到我们第一次发现的提交有什么区别呢？

$ git diff ba0b2d348f4e33857c96acf5a6231cf9d89ddb1b..dde61dae0cf648e7f4dd8a5c194bcf9be1745793 | grep "127.0.124.1" # remove grep to see full diff
-       return "127.0.124.1"

在这里我们找到了它。太奇怪了。但是由于我们在提交之间使用了差异，我是否犯了一个错误，并且之间还有其他提交？

$ git log --pretty=oneline ba0b2d348f4e33857c96acf5a6231cf9d89ddb1b..dde61dae0cf648e7f4dd8a5c194bcf9be1745793
dde61dae0cf648e7f4dd8a5c194bcf9be1745793 network interface

不，我们似乎没有犯错。太奇怪了。但是，是的，那是我找到弦消失的特定变化点的距离。

另外

我可以确认使用git bisect的是dde61dae0cf648e7f4dd8a5c194bcf9be1745793就是犯我一直在寻找。

# bisecting a while...
$ git bisect bad 
dde61dae0cf648e7f4dd8a5c194bcf9be1745793 is the first bad commit
commit dde61dae0cf648e7f4dd8a5c194bcf9be1745793
Author: ...
Date:   Fri Oct 18 11:04:26 2019 +0200

    network interface

:100644 100644 242e81c363c2c7069efb018821821553b98f2c97 416c27f5351a9d92a6914b34846c6de51d83dd0d M      go.mod
:040000 040000 715c3ab5b3f4579d8054618f1e11fc05fb425324 e6731408a1ac1ff0428128ccbb1fbfaad4c789ab M      network
[...]