So when I create a new branch, do stuff and want to merge back to master, I should rebase instead ? (assuming nothing else was done such as pushing elsewhere etc).
Yeap, the advice here is that you should use `pull --rebase` instead of `pull`. What that does is it eliminates the merge commit to the "central" branch (e.g. on github). That is it fakes the history to look as if you started to work on a branch with all the commits applied and so there were no merges necessary.
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.
Rebase is polite, imho. You probably want a pull request that is "clean" for the code reviewers. And future bug chasers. A bunch of interleaved commits makes it harder for anyone to reason about the code history.