git - merge pull 请求时，提交出现在本地不存在的 GitHub 上

Question

设置

我刚刚在 GitHub 上与以下两位家长创建了一个 pull 请求:

2 个 parent :184... + 3fb...:

• 184 是 master 上的最后一次提交，也被推送到 来源/主人
• 3fb 是我的功能分支上的最后一次提交。

3fb 是我的功能分支上的最后一次提交。

我正在运行 TravisCI 并注意到它实际上为每个新的 PR 运行了两次，在这种情况下它是为 3fb (从上面)和一些新的提交运行的，我认为这是184 和 3fb 的组合 - 假设它有提交哈希 68b。

问题

当我单击“merge ”并下 pull 生成的主分支时，我希望看到 68b，但我看到的却是一个新分支(为了完成，它是 a64).我在本地的任何地方都看不到 68b!

当我尝试在本地检查 68b 时，我得到了 fatal: reference is not a tree: 68b。

技术上这是怎么回事？为什么我从来没有在本地获得此提交？

Answer 1

细节因 CI 系统而异，但一般来说，CI 系统构建特定的提交。 GitHub pull request 可能还没有提交。¹ 因此，在这种情况下，Travis-CI 大概做出了它自己的 提交，然后对其进行了测试成功地。那就是您观察到的 68b。

[编辑:GoodDeeds commented that Travis-CI does use the trial merge that GitHub makes ，这破坏了这个特定的理论。但是仍然有几种方法可以获得相同的结果。]

When I click Merge ...

由于这发生在 GitHub 本身(而不是 Travis)上，GitHub 现在他们自己提交。因为每个提交都有一个完全唯一的哈希 ID，所以这个 不会 68b。 编辑:或者，如果 GitHub 可能每次都进行新的提交，而不是重新使用他们之前进行的试验性 merge 。

... and pull down the resulting master branch, I expect to see 68b, but instead I'm seeing a new one (for completion's sake, it's a64). I do not see 68b locally anywhere!

据推测，GitHub 创建的那个在单击按钮后以 a64 开头。 (唯一性约束导致长而难以处理的完整哈希 ID。只要结果明确，Git 就会让您缩写，但实际的最小值为 4 个字符，而不是您在此处使用的 3 个字符.)

您可以告诉 GitHub 不要进行常规 merge ，而是进行压缩 merge 或 rebase merge merge 。这些都不使用任何现有的 merge 提交，因此这两个操作总是会产生一个您自己的 Git 以前从未见过的新的、唯一的哈希 ID。

---

¹有些 GitHub PR 有，有些没有。如果 GitHub 确实进行了 merge ，则可以从 GitHub 获得该提交。其他托管系统的行为可能会有所不同，并且某些 CI 系统可能不会使用 GitHub 在这一点上可能已经或可能没有做出的 potentially-tentative-anyway 提交，而是选择自己做。虽然我使用过 Travis-CI，但我从未对其进行足够的调查以准确了解它在这里的作用。