[adamsilkey]

Merge isn't superior to rebase; they're both tools with different purposes.

Have you ever squashed down a branch before merging back into main? Then you've used rebase.

The purpose of source control (not just git) is to keep a useful version history of your project. If you don't need to know where/when a commit originally branched off from, rebase can keep a cleaner history than merge.

Even rebasing a branch off the latest commit just to merge back in can be useful.

[riperoni]

I never use squashing, because the history would not be easily accessible afterwards.

In popular Git ecosystems like Github you have the option to add a merge commit. To me, this also helps understanding the history of the repo. Would the rebasing be equally visible?

[seba_dos1]

Rebasing is usually (but not exclusively) useful before pushing to the shared repo, at a point when there's no proper history being added to it yet, so you can put your changes into shape before actually publishing them. Learning how to effectively use rebase and its all goodies is one of the most useful things that git has to offer and almost transforms the way you work with version control, as with it you're able to utilize its power in more areas than if you only ever commit and push. For me, git is not just a collaboration tool - it's also an "undo" log on steroids; something that extends my text editor and lets me manage the changes regardless of whether they're meant to ever leave my PC or not.

Git is a powerful data structure manipulation tool. Use it as such and harvest that power. After all, what you're working on is just a graph of repository states - and you can attach any meaning you find useful to those states.