When merging pull request, commit appears on GitHub that doesn't exist locally

Question

Setup

I have just created a pull request on GitHub with the following two parents:

2 parents: 184... + 3fb...:

• 184 is the very last commit on master, had also bee pushed to origin/master
• 3fb is the very last commit on my feature branch.

3fb is the very last commit on my feature branch.

I am running TravisCI and noticed that this is actually being run twice for each new PR, in this case it was run for 3fb (from above) and some new commit, which I assume is the combination of 184 and 3fb - let's say this has commit hash 68b.

Problem

When I click 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!

When I try to check out 68b locally, I get fatal: reference is not a tree: 68b.

What's going on technically here? Why do I never get this commit locally?

Answer 1

The details vary from one CI system to another, but in general, CI systems build a specific commit. A GitHub pull request may not have a commit yet.¹ So presumably Travis-CI in this case made its own commit, which it then tested successfully. That was the 68b you observed.

[Edit: GoodDeeds commented that Travis-CI does use the trial merge that GitHub makes, which wrecks this particular theory. But there are still several ways to get the same result.]

When I click Merge ...

Since this happens on GitHub itself (not on Travis), GitHub now make their own commit(s). Since every commit has a totally-unique hash ID, this one won't be 68b. Edit: Or, if GitHub may make a new commit every time, instead of re-using the trial merge they made earlier.

... 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!

Presumably, then, the one GitHub made, upon clicking the button, starts with a64. (The uniqueness constraint results in the long and too-hard-to-deal-with full hash IDs. Git will let you abbreviate as long as the result is unambiguous, but the actual minimum is 4 characters, not the 3 you have used here.)

You can tell GitHub not to do a regular merge, but instead to do either a squash-merge or a rebase-and-merge. Neither of these use any existing merge commit, so both of these actions always result in a new, unique hash ID that your own Git has never seen before.

---

¹Some GitHub PRs do, and some do not. If GitHub did make a merge, that commit is available from GitHub. Other hosting systems may behave somewhat differently and some CI systems may not use the potentially-tentative-anyway commit that GitHub may or may not have made at this point, choosing to just make their own. While I have used Travis-CI, I've never investigated it enough to know precisely what it does here.