I use to work for some company that has a very strict no-merge, only rebase policy, because they want to preserve a straight-line commit history. But I think what they actually need is an algorithm that can draw / print commit history in straight. To me, altering the model for the sake of view kinda of defeated the purposes.
What purpose?
If the workflow consists of many small fixes/changes that are entirely contained inside a commit or two, there's not really any good reason to merge (with a merge commit) instead of rebase.
For example, with rebase:
- You get a clean linear commit graph for each branch. It's true you can mostly achieve this with merge with some clever merge-commit-collapsing algorithm but that doesn't scale well since each person has his favorite git tool (command line, external git program, built-in git extension of the IDE, etc.)
- The linear commit graph isn't just for eye candy. A lot of git operations are simpler with this type of graph. Want to count how many commits from HEAD you need for interactive rebase? Easy. Want to squash some commits, reordering them, and other complex operations? Easy. It gets a lot more complex when you have merges all over the places.
- Rebase forces the developer to always be on top of the target branch (at least before the pull request is "accepted"). This means conflicts are resolved earlier and the dev is more likely to test his changes with the latest code.
If you care about how the code in a commit(s) evolved to that final state, there's always the code review history in GitHub/GitLab/gerrit/reviewboard/etc.
Merge has its place (e.g. a long-lived feature branch that will eventually be merged into a main branch). But for one-off branch for fixes/small changes you're better off with rebase.
If you don't think this intermediate commits will ever have value, in my opinion you may as well squash them.
I have, on some occasions, run at least basic tests on all commits in a rebased branch but few people bother (and with github, where someone merges a PR by rebase, it would be obvious there was a problem until it was too late).