我刚刚在GitHub上创建了具有以下两个父项的拉取请求：
2 parents: 184... + 3fb...：
184是对master的最后一次提交，也已将蜜蜂推送到
origin/master 3fb是我的功能分支上的最后一次提交。 3fb是我功能分支上的最后一次提交。
我正在运行TravisCI，并注意到实际上每个新的PR都运行了两次，在这种情况下，它是为3fb（从上面）运行的，并进行了一些新的提交，我认为这是{ {1}}和184-假设它具有提交哈希3fb。
当我单击“合并”并下拉所得的主分支时，我希望看到68b，但我看到的是一个新分支（为完成起见，它是68b）。我在任何地方都看不到a64！
当我尝试在本地结帐68b时，我得到68b。
技术上这是怎么回事？为什么我永远不会在本地获得此提交？
答案 0 :(得分：2)
每个CI系统的详细信息各不相同，但通常，CI系统会构建特定的提交。 GitHub pull request 可能还没有提交。 1 因此，在这种情况下，Travis-CI可能做出了自己的提交，然后对其进行了测试。成功。那就是您观察到的68b。
[编辑：GoodDeeds commented that Travis-CI does use the trial merge that GitHub makes，破坏了这一特殊理论。但是仍然有几种方法可以得到相同的结果。]
当我单击“合并...”时
由于这是在GitHub本身上发生的（不是在Travis上发生的），因此GitHub现在自己做出自己的提交。由于每个提交都具有完全唯一的哈希ID，因此该不会为68b。 编辑：或者，如果GitHub每次都可以进行新提交，而不是重新使用他们之前进行的试用合并。
...，然后下拉生成的master分支，我希望看到
68b，但是我看到的是一个新分支（为完成起见，它是a64）。我在任何地方都看不到68b！
然后，大概是，在单击按钮后制作的一个 GitHub 以a64开头。 （唯一性约束导致具有完整的哈希ID的时间太长且难以交易。只要结果明确，Git会让您缩写，但实际的最小值是4个字符，而不是您在此处使用的3个字符）
您可以告诉GitHub不要进行常规合并，而要进行squash-merge或rebase-and-merge。这些都不使用任何现有的合并提交，因此这两个操作总是都会产生一个新的，唯一的哈希ID，这是您自己的Git从未见过的。
1 某些GitHub PR有，有些则没有。如果GitHub确实进行了合并，则可以从GitHub获得该提交。其他托管系统的行为可能有所不同，某些CI系统可能此时不使用GitHub可能做出或可能没有做出的潜在尝试性提交，而是选择自己制作。当我使用Travis-CI时，我从来没有对其进行足够的研究以确切地知道它在这里做什么。