> Are there any good reasons why someone should try to rebase and merge (fast-forward) a pull request to avoid a merge commit? I've always thought of it as a w

> Are there any good reasons why someone should try to rebase and merge (fast-forward) a pull request to avoid a merge commit? I've always thought of it as a way to effectively create a branch, do your work, and fast-foward merge it back in to the main branch without having any other work included in it. To put it another way, let's say you create a fork, do your work, and in the interim, several other contributors do the same thing and merge their work back into the main repo. Now, you could merge the mainline back into your fork and have a merge commit in your private branch that shows the changes that the other contributors made since you created your branch, or you could merge your branch back into the main branch at the end and have it show that it branched off earlier than the current head of the main branch. In the first case, you now have a commit that shows changes that you didn't actually make. In the second case, it shows that you didn't base your work on the latest version of the main branch. In contrast, if you rebase and only merge your work into the main branch via a fast-forward merge, your branch will only show commits that you made and it will effectively show that it was based on the latest version of the main branch before it was merged back in.