On PR #519 @erossignon suggested changing the default merge strategy from "Allow merge commits" to "Allow rebase merging". Rebasing would allow having a more linear history in the master branch where the current approach is to have merge commits of different PRs. I work with both approaches in different repositories and I have to admit I like both of them.

My take is that the current approach becomes not useful when you have a lot of feature branches (a.k.a. PRs) in a short amount of time. I personally like the fact that you can understand from which PR a change was generated and use this information to look back in Github the discussion history. But of course, when you merge 20/30 Prs a week the thing is not really manageable. But this is not the case yet, looking at node-wot git graph I can still tell what's going on:

Please share you thoughts about this topic below :)