Anecdotally, I feel it's less common than merge commits. There are plenty of places driven by the "Merge Pull Request" button in GitHub and that's the default functionality.

In personal projects or those with fewer developers, I prefer rebase + FF merge for a clean history. I don't really feel the need to see the merge commit in the master branch history.

it comes down to whether you want your version history to reflect the true version of development's history (merge), or a simpler, doctored version of history which reflects the final deliverable (rebase). advocates of the latter, myself included, argue that it eliminates noise and tells all the story that needs to be told -- and that the original history can be preserved by not deleting the feature branches. others argue that changing your parent commit is dangerous and occlusive.

i think the core of it comes down to the UX for "git log", which attempts to display history linearly when in fact it absolutely is not. ask yourself: what is the _contents_ of a merge commit? if you know git well, you know that the merge commit contains everything from the feature branch... and that the feature commits you see when you run "git log" on master are actually not on master at all. so the rebase strategy makes master truly linear to match the tools and reduce cognitive load.

however, the rebase strategy does introduce new possibilities of tool-driven bugs and requires more rigor. this article has a good run-down of the risks:

https://medium.com/@fredrikmorken/why-you-should-stop-using-...

the classic example of a rebase pitfall is:

a) you branch from master,

b) on your feature branch, develop a feature utilizing dependency x,

c) meanwhile, on master, another developer removes dependency x,

d) you rebase back on top of master -- there are no conflicts, and things look good, but the build is completely broken.

Yes, it's common for open source projects. I've used a rebase workflow for feature branches in Apache projects and others.

It takes a little more work for each contributor but leaves history on master very clean.