如何搜索Git仓库历史记录以查找合并错误？

Question

在我们的历史记录中，有些git开发分支被合并了。但是，错误的合并决策导致一些代码没有进入我们预期会在主分支中的代码库。（在最终合并到主分支之前，有多个不同分支的合并。因此，分支和合并历史相当复杂。）

有没有一种简单的方法搜索git代码库以确定哪个合并上做出了“错误”的决定？

（我已经知道这个特定情况的答案，但找到它的过程有点繁琐。）

编辑： git blame命令无法解决问题，因为该行代码在合并错误之后的某个提交中被修改过。

- Atlas1j

Answer 1

如果没有更多细节，我只能提供可能的解决方案。如果您知道受影响的文件或行，可以尝试使用git-blame（git blame *file* 或 git blame *revision* *file*），或者可以尝试所谓的“pickaxe搜索”使用git-log，即 git log -S'*line* 尝试查找引入给定行或删除给定行的修订版本。您可以通过 git log -p -m --grep=Merge 查找和检查所有合并，例如，并检查它们与其父项的关系（-m 显示到所有父项的差异；或者-c 显示组合差异但不显示微不足道的合并更改，即如果选择了一侧）。

- Jakub Narębski

Answer 2

在您的情况下，git-bisect 能帮上忙吗？

- J.F. Sebastian

Answer 3

Git日志具有强大的搜索选项。如果你知道一个消失的代码块，你可以搜索那段代码。

git log <HERE>..<THERE> -S"我关心的行" --diff-filter=M

将在从HERE到THERE的范围内搜索-S后面的字符串，并仅在该行被修改（添加或删除）时进行搜索。

如果使用-G而不是-S，您可以在搜索中实现更高的精度。-G提供正则表达式搜索，而不是使用-S的字符串字面搜索。

- Matthew McCullough

---

这太棒了！我不知道这个。谢谢！ - Bruno Bronosky

这在使用 -p 选项显示补丁而不是提交摘要时非常有用。因此，您实际上可以看到与提交匹配的更改。 - studgeek

请注意，要使其正常工作，必须添加选项“-c”。否则，“git log”将跳过合并提交引入的更改。 - sleske

Answer 4

如果你知道一个文件中被git分支合并修改的行，你可以执行 'git blame file.txt' 命令，确定该行在文件中的提交哈希值和提交者。然后，你可以查看git日志，并找到与坏的分支合并相关的确切提交。

编辑： 回应作者的评论，如果你正在寻找某一行消失的情况，那么 'git diff' 结合 grep 和二分查找可能是你想要的。假设你有提交号 0、1、2、3、4、5、6。你知道该行存在于版本 0 中，但在版本 6 中消失了。使用 'git diff' 加上 grep 来搜索该行的消失。

git diff 0 6 | grep '- line I care about'

第一次迭代时，您会看到您关心的行消失了。然后将修订号减半并再次尝试。

git diff 0 3 | grep '- line I care about'

如果grep仍然显示该行消失（带有“-”符号），则您知道该行在修订0到3中消失。如果grep没有显示该行消失，则该行在修订4-6中消失。

不断将修订版本减半，直到找到罪魁祸首。

- funkyworklehead

---

问题是在“合并错误”之后的某个时候触及了这行代码。我知道补丁是何时引入的，但很难确定它何时首次消失。 - Atlas1j

不要使用git diff和搜索，而是使用git log提供的选项。具体来说，请尝试git log <HERE>..<THERE> -S"line I care about" --diff-filter=M。 - Matthew McCullough

你所描述的过程就是git bisect所做的。然而，你不必计算哈希值。虽然你的0-6、0-3/4-6等模式很清晰易懂，但你不能使用提交编号。你必须使用提交哈希值，这一点并不清晰。git bisect是你的好朋友。 - Bruno Bronosky

Answer 5

对于其他寻求更简单解决方案的人，可以启动gitk（或从Git GUI转到存储库>可视化X历史记录），并使用其查找工具。

- Walf