Can GitHub rebase instead of merge, like Gerrit?

I did some Gerrit code review and found that, once we click "Submit" on a Gerrit page, it doesn't do a merge, but rather do a "rebase" (more accurately, some cherry-picks), so that the history is linear and all the small commit histories of me would go into that linear history, and there is no "merge" commit.

And then I tried similar operations on GitHub: just fork a repo and then edit on the web and created a pull request, and let the original repo accept that pull request by merging.

And then I saw in SourceTree that it is a "merge", not a "rebase", so the history is not linear... but I still see all the commit history if I do git log, probably just sorted chronologically.

But the question is, can GitHub do a rebase just like Gerrit? It shouldn't really be hard to do: when the user can click "Merge" on GitHub, just check and see if a rebase is all fine and just change the "Merge" button to "Merge by rebase" or "Accept the changes (as a rebase)" and it would work just like Gerrit and rebase is the way that many repo owners prefer it. So can GitHub do a rebase just like Gerrit?

Solution

GitHub offer a green "merge" button with a dropdown arrow to one side. Clicking on the dropdown arrow lets you change the operation:

Merge: does the equivalent of a normal git merge
Rebase and merge: does a rebase, as if by git rebase --force, and then a fast-forward of the resulting copied commits
Squash and merge: does the equivalent of running git merge --squash, more or less

The middle one of these three options is similar to what Gerrit would do, but it's not clear to me whether Gerrit has the (mis?)feature of effectively doing a git rebase --force first.

The forced rebase means that you—the person clicking the merge button—become the committer of the new commits, and all the commits have new, different hash IDs, even if the originals could have been used as-is, and even if you were the committer of the original commits. (If you are not the original committer, that would be a good excuse for forcing the rebase like this.)