我正在尝试确定由于使用合并ID进行合并而引入父分支的提交。
答案 0 :(得分：2)
命令git log <id>~1..<id>将列出所有合并的提交，以及合并提交本身。
答案 1 :(得分：1)
使用max630's answer，只要它是真正的合并。要排除合并本身，请使用它的略微变体：M^1..M^2。
您在这里要求的是找到由于合并而变为可以的提交。这种可达性的想法是图论理论的概念。因此，如果您绘制合并的结果，答案就更清楚了。
假设合并之前的＆＃34;＆＃34;图看起来像这样，其中*是合并基础提交，L和R是左侧和右侧提示：
...--*--...--L <-- mainline
\
o--...--R <-- sidebranch
然后＆＃34;合并后＃34;图看起来像这样：
...--*--...--L---M <-- mainline
\ /
o--...--R <-- sidebranch
新引入的提交现在显然是:-)沿着底行的那些，即可以从（并包括）R到达的那些，但不包括合并基础提交。我们从M的第二个父项R开始，然后从R到其父项的后向连接，再到另一个父项，以及依此类推。这些导致到底部o节点，该节点连接回提交*。
如果您的sidebranch名称指向R，则只需找到合并基础：
mb=$(git merge-base $all mainline^1 sidebranch)
使用＆＃34;提交的第一个父级＆＃34;用于从提交L标识提交M的语法：^1后缀。如果您不再具有名称sidebranch，则可以使用＆＃34;提交的第二个父项来识别提交R。语法：
mb=$(git merge-base $all mainline^1 mainline^2)
不幸的是，这不是唯一可能的输入图。在合并之前有一个＆＃34;非常典型。看起来像这样的图：
...--* <-- mainline
\
o--...--R <-- sidebranch
在没有git merge的情况下运行--no-ff将执行＆＃34;快进＆＃34;操作，实际上不是合并：你最终得到一个线性图并且没有合并提交：
...--*--o--...--R <-- mainline, sidebranch
在这里，除非您仍然拥有主线分支的reflog条目，否则几乎不可能找到commit *。如果你做有reflog条目，那么它很简单：它是mainline@{number}，使用适当的 number 。 （找到适当的 number 是一个查看reflog以查找来自快进的更新的问题。如果你刚刚进行了合并，那么它只是{ {1}}也是1。）
HEAD@{1}我在上面找到合并基础的示例命令中放置mb=$(git rev-parse mainline@{1}) # for instance
的原因是，当您有多个合并基础时，还有第三种可能性：
$all在这里，您需要排除所有合并基础。如有必要，请将...--o--*---o--...--L
\ /
X
/ \
...--o--*---o--...--R
替换为$all。
现在您已经知道合并基础，如果合并是真正的合并，那么找到它们--all，合并可以访问的提交只是从git merge-base可以访问的提交本身，但不是来自合并基地：
R如果您想检查提交而不是简单地枚举它们，请使用git rev-list sidebranch --not $mb
而不是git log。
以上所有内容旨在查找合并库并将其排除，以便我们获得提交git rev-list及其可访问的祖先，而无需从R获取任何提交。但是，我们不必特别从合并基础开始这种排除。我们可以从L本身开始。
要命名L，我们只需要命名L的先前值或合并mainline的第一个父级。 M的第一个父级是M或M^1，因此只要我们知道M~1的哈希ID，我们就可以添加后缀并说出＆＃34;排除这些＆＃34;。
甚至还有一个简短的语法。而不是：
M或略短：
git rev-list M^2 --not M^1
我们可以使用双点语法：
git rev-list M^2 ^M^1
这就是我们在顶部所拥有的。
请注意，所有这些都假设＆＃34;真正合并＆＃34;：如果合并是快进，则必须改为使用reflog。
答案 2 :(得分：0)
您可以签出分支并使用git log查看分支中的提交和提交ID。
git log -n10 --oneline将为您提供该分支中前10次提交的历史记录。