设置
我刚刚在GitHub上与以下两位家长创建了一个拉取请求：
2 parents: 184... + 3fb...:
184是master上的最后一个提交，也被推到了origin/master3fb是我的功能分支上的最后一次提交
3fb是我的功能分支上的最后一次提交。
我正在运行TravisCI，注意到这实际上是为每个新PR运行两次，在这种情况下，它是为3fb(从上面开始(和一些新的提交运行的，我认为它是184和3fb的组合-假设它有提交哈希68b。
问题
当我单击Merge并下拉生成的主分支时，我希望看到68b，但实际上我看到的是一个新分支(为了完成起见，它是a64(。我在本地任何地方都看不到68b！
当我尝试在本地签出68b时，我得到了fatal: reference is not a tree: 68b。
从技术上讲，这里发生了什么？为什么我从未在本地获得此提交？
每个CI系统的详细信息各不相同，但通常情况下，CI系统会构建特定的提交。GitHub拉取请求可能还没有提交1因此，在这种情况下，Travis CI大概做出了自己的提交，然后成功地进行了测试。这就是你观察到的68b。
[编辑：GoodDeeds评论道，Travis CI确实使用了GitHub进行的试合并，这破坏了这一特定理论。但仍有几种方法可以获得相同的结果。]
单击"合并"时。。。
由于这种情况发生在GitHub本身(而不是Travis(上，GitHub现在让自己提交。由于每个提交都有一个完全唯一的散列ID，所以这个不会是68b编辑：或者，如果GitHub每次都会进行新的提交，而不是重新使用他们之前进行的尝试合并。
。。。并下拉生成的主分支，我希望看到
68b，但我看到的是一个新的分支(为了完成起见，它是a64(。我在任何地方都看不到68b！
那么，点击按钮后，制作的GitHub可能以a64开头。(唯一性约束导致完整的哈希ID太长，太难处理。只要结果明确，Git就会让你缩写，但实际最小值是4个字符，而不是你在这里使用的3个字符。(
你可以告诉GitHub不要进行常规合并，而是进行挤压合并或重基合并。这两个操作都不使用任何现有的合并提交，因此这两个操作总是产生一个新的、唯一的哈希ID，这是您自己的Git以前从未见过的。
1有些GitHub PR会这样做，有些则不会。如果GitHub确实进行了合并，那么该提交可以从GitHub获得。其他托管系统的行为可能有所不同，一些CI系统可能不会使用GitHub目前可能做出或可能没有做出的潜在的尝试性承诺，选择只做出自己的承诺。虽然我使用过Travis CI，但我从未对其进行过足够的调查，无法确切了解它在这里的作用。