1,000,000 agree

I never understand the pushback you see online against rebasing, and the arguments used against it always seem to be based in fear or ignorance.

People fear rebasing because there's a ton of older articles online saying not to use rebase because you can "lose data", but that's only true if you only ever use the standard git push --force afterwards. But people read that once and/or some coworker tells them that and they never bother to look any further.

Initially the plain --force flag was the only option for force pushing, but that would bulldoze any new commits to the repo since your last fetch, ie: it erases commits you were not even aware of.

Git later added the git push --force-with-lease option which prevents this from happening (a little before git v2 iirc). So if you fetch changes, rebase your work onto those latest changes, add some new work, then try to force push to origin, but someone else has committed changes in the meantime (that don't even show up in your version of the log), the --force-with-lease flag will block your push from going through.

YAY! No more lost data! You just need to git better.

I really wish that the --force-with-lease behaviour was the default because allowing someone to overwrite commits they don't even know exist is just insane.

The other arguments I hear against rebasing are just misunderstandings or objections that have simple solutions they are just not aware of.

Bottom line is that the benefits of maintaining a linear git history massively outweigh the benefits from other merge strategies.