如何判断一个提交是否是另一个提交的后代？

使用Git，如何确定分支中的一个提交是否是另一个提交的后代？

如果要以编程方式（例如，在脚本中）检查此内容，则可以检查是否git merge-base A B等于git rev-parse --verify A（那么A可以从B到达），或者是否等于git rev-parse --verify B（那么B可以从A到达）。 git rev-parse需要从提交名称转换为提交SHA-1 /提交ID。

git rev-list在VonC中使用like 回答也是可能的。

编辑：在现代Git中，该查询以的形式明确支持git merge-base --is-ancestor。

如果你问提交的一个约是一个分支的顶端，然后git branch --contains <commit>或者git branch --merged <commit>可能是更好的非编程解决方案。

从Git 1.8.0开始，作为以下选项的支持merge-base：

git merge-base --is-ancestor <maybe-ancestor-commit> <descendant-commit>

从手册页：

-是祖先

检查第一个是否是第二个的祖先，如果为true，则以状态0退出；否则，则以状态1退出。错误由非零的非1状态表示。

例如：

git merge-base --is-ancestor origin/master master; echo $?

这种操作依赖于SO问题中详细介绍的修订范围的概念：“ 'git log origin / master'与'git log origin / master ..'之间的差异 ”。

git rev-list 应该能够从一次提交退回，直到可以到达为止。

所以我会尝试：

git rev-list --boundary 85e54e2408..0815fcf18a
0815fcf18a19441c1c26fc3495c4047cf59a06b9
8a1658147a460a0230fb1990f0bc61130ab624b2
-85e54e240836e6efb46978e4a1780f0b45516b20

（边界提交的前缀为-）

如果显示的最后一个提交与git rev-list命令中的第一个提交相同，则它是从第二个提交可到达的提交。

如果第一次提交与第二次提交不可达，则不git rev-list返回任何内容。

git rev-list --boundary A..B

A如果A可以到达的话，将会结束B。
它与：

git rev-list --boundary B --not A

与B一个正参考，和A一个负参考。
它将从开始B并在图形中返回，直到遇到可从到达的修订A。
我认为，如果A可以直接从到达B，它将遇到（并且由于--boundary选择而显示）A本身。

另一种方法是使用git log和grep。

git log --pretty=format:%H abc123 | grep def456

如果提交def456是提交abc123的祖先，则将产生一行输出，否则将不输出。

通常可以省略该--pretty参数，但是如果要确保只搜索实际的提交哈希而不搜索日志注释等，则需要这样做。

https://stackoverflow.com/a/13526591/895245提到了它，现在使其更加人性化：

git-is-ancestor() (
  if git merge-base --is-ancestor "$1" "$2"; then
      echo 'ancestor'
  elif git merge-base --is-ancestor "$2" "$1"; then
      echo 'descendant'
  else
      echo 'unrelated'
  fi
)
alias giia='git-is-ancestor'

git show-branch branch-sha1 commit-sha1

哪里：

• branch-sha1：要检查的分支中的sha1
• commit-sha1：要检查的提交的sha1

如果您正在使用 git merge-base --is-ancestor，请确保使用Git 2.28（2020年第三季度）

在Git 2.28（2020年第三季度）中，“struct commit ”中并非总是存在已移至提交楼板。

请参阅Abhishek Kumar（）的提交c752ad0，提交c49c82a，提交4844812，提交6da43d9（2020年6月17日）。^{（通过合并JUNIOÇ滨野- -在提交d80bea4，2020年7月6日）}abhishekkumar2718
gitster

commit-graph：介绍 commit_graph_data_slab

^{签字人：Abhishek Kumar}

在许多情况下都使用struct commit。但是，成员generation和graph_pos仅用于与提交图相关的操作，否则会浪费内存。

当我们过渡到第v2代时，这种浪费会更加明显，而第2代使用64位的代号而不是当前的32位。

由于经常commit_graph_data将它们一起访问，因此让我们介绍struct 并将其移至commit_graph_data平板。

尽管整个测试套件的运行速度与一样快master（系列：26m48s，master：27m34s，速度提高了2.87％），但是某些命令（如SzederGábor所发现的git merge-base --is-ancestor速度却降低了40％）。 最小化提交面板访问后，速度降低仍然存在，但接近20％。

Derrick Stolee认为，速度下降的原因是底层算法，而不是提交板访问的速度慢，我们将在以后的系列文章中进行跟踪。

如果您需要对存储库中的所有标签执行此操作，请建立在itub的答案上：

for i in `git tag` ; do echo -ne $i "\t" ; git log --pretty=format:%H $i | (grep <commit to find> || echo ""); done