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.