使用git cherry，可以检查哪些提交已经应用到另一个分支，通常是上游。但是，这仅返回非合并提交。 git log --cherry ... 也排除了合并提交，因为它暗示了 --no-merges。
如果已使用-x 挑选了提交，则源修订包含在提交消息中，因此至少可以git log --grep 进行修订并检查它是否已经存在。
如果在cherry-picking时没有使用-x，我怎样才能稳健地检测一个合并提交是否已经被挑选到一个分支？
【问题讨论】：
标签： git merge git-cherry-pick git-cherry
但是，这只会返回非合并提交
有充分的理由：您不能盲目地挑选合并，挑选合并的提交而不是合并的结果总是更干净、更安全。
不过，这是 Git。您可以从一个技巧或另一个技巧中挑选结果的差异，但请注意，这将导致任何冲突解决方案，并且这些是特定于该合并的，即合并自合并基础以来的两个历史，而不仅仅是一个，并且所以不是你想像这样随便变基的东西。
如果您发现自己无论如何都不得不这样做，那么扩展 git cherry 为您自动执行的功能并为您使用的差异生成补丁 ID 并不难，
git show -m $themerge | git patch-id
并在其他历史记录中查找具有相同补丁 ID 的提交，但我很难想象有人会认为他们这样做会获得什么。像这样擦除 Git 的合并记录可能不会对你的编译器撒谎，但它充其量只是一种小众用法，它会禁用几乎所有 Git 的内容跟踪机制，让你做大量的手动记录保存和手动工作从这些记录中挖掘和推断，以弥补您花费大量精力擦除的 Git 记录。
【讨论】：
For good reason: you can't blindly cherry-pick merges, it's always cleaner and safer to cherry-pick the merged commits instead of the merged result.：如果合并引入了原子更改，我不确定为什么使用单个提交而不是合并会更干净/更安全？埃斯。在 master 基本上只有合并的存储库中，并且明确定义了我需要从合并中获得哪个父级。当我变基时，git 会自动检测合并的 PR 并将它们从列表中删除。我只是在寻找一种方法来检查 git 已经做了什么，而不需要实际去做。