目标（X）：我正在git checkout中查看文件中的特定行。 git blame告诉我，此行（以当前形式）首先在commit 1234abcd中提交，这是几个月前我的一位同事在自己的仓库中进行的一次提交。稍后，它被合并到我们的master分支中。 我想找到合并提交。
Y0 ：到目前为止，我发现最好的方法是运行
git blame master~42 path/to/file/in/question | grep ^1234abcd
表示42的各种值，然后进行二进制搜索以找到包含相关代码的master的最早的 direct 祖先。这在实践中可行（因为我们的主分支机构遵循严格的“不推而进，仅PR”政策），但麻烦。
Y1 ：我想，只要我能得到git log来向我展示所有提交内容，我就能迅速找到合并
1234abcd作为祖先不幸的是，似乎用于指定修订范围的Git表示法无法表达第三个条件。 1234abcd..HEAD语法（直觉上会期望这样做）反而给我“ HEAD的祖先，而不是1234abcd的祖先”，因此显示了在我执行之后master分支发生的所有其他活动同事从工作分支分支出来，该分支后来合并了。当起始点是提交图中的“捏点”时，这种语义可以说是有用的，但对于跟踪随机工作提交的命运却没有太大作用。
问题：有没有办法完成Y1？ （也就是说，编写我自己的程序以解析提交图并计算可达性关系的方法是简短的）。还是有更好的方法来实现X？
（一个幼稚的方法是不入门的：如果我知道同事进行更改时同事使用哪个名称来表示他的工作分支，我可以搜索提交注释，以找到一个将特定分支合并到master中的注释。 ，过去的分支名称不会记录在存储库中的任何地方，并且实际上，提交注释可能是该分支名称现在仅存在的 位置。