[oelmekki]

I suppose you are talking about making pull requests for an upstream repository owned by someone else (typically : making a pull request to an open source project), in which case you ask to merge your master in their master ?

When working on a repository where you make a pull request from a feature branch to master in the same repos (typically : your company private repos), I would rather merge the feature branch in master rather than rebasing it, at least to know at which point a dev work has been merged.

The same logic stand, though. If developer has used several branches to build her feature, I don't want to know about it : she must rebase them instead of merging them.

Additionally, I like pull requests to master branch to be in a single, well documented commit. So I encourage developers to make a lot of small commits, then use `git rebase -i` to squash them into a single commit with a long and detailed commit message (the one-line previous commit messages being used to write a changelog). Using github, this has the advantage that the commit message of a single commit pull request is automatically pre-filled as pull request message.