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).
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.