[crugej]

If you want to keep the individual commits rather than squash the into a single commit. This is useful if the author of the PR actually wrote good commits that you don't want to make into a single commit. I'm also thinking of the case where a squash could turn a series of commits into a single commit with a massive amount of changes that is harder to grok when going back historically.

[poorman]

So it's like the old "merge", but doesn't create another commit when you close the PR?

[morinted]

Yes -- a merge merges one branch into another, and creates a merge commit while doing so.

A rebase rewrites history, as if the PR had been written on master directly. There is no merge commit and no evidence of a previous branch. Some people prefer rebasing over merging because it gives you a linear commit history.

[prophetjohn]

This is not correct. What you're describing is two different styles of merging: fast-forward and no fast-forward, as indicated by the `--no-ff` and `--ff-only` flags provided to `git-merge`

`git-rebase` will rewrite the history of the current branch. In this case, github will rewrite the history of the branch that you would like to merge such that the base commit (hence the name "rebase") or the commit that was branched off of is the latest commit on the default branch (usually master)

Then when you merge it, you'll get a merge commit or not depending on whether or not you do a fast-forward merge