Well, it’s sad to see a fair argument thrown behind a clickbait title. Even given the points made, the conclusion would be of “pay attention to your flow” and “use git rebase carefully”, at most. Stop using it? I wouldn’t think so.

It all boils down to something that will always hold true: “your history should remain true”.

Exactly. This means that:

• your feature branch truth = target branch (master/develop/whatever) + your work on top
• target branch truth: a history of merge commits reflecting when work (features) has been added

The first means that until delivery, your work must be kept on top (via rebasing). On delivery they get merged.

It can be difficult to rebase? Sure. That’s why it’s good to squash your work. If you need to keep a copy of your thought process, you can always keep a local copy for your reference.

You are worried about FF messing up the ‘truthiness’ of your master? There’s always — no-ff option there, ensuring a merge commit is present.

Yes, on master a linear history would be fake (so use — no-ff accordingly). But elsewhere not so much.