That's the simple and safe use of rebase. Rolling up your local wip commits into a coherent story of one or a few clearer commits.
The more-complicated but still safe use is to rebase your local branch on top of an advanced upstream before pushing. Some people prefer merge for this case, but it is somewhat impure.
The problematic use of rebase is on pushed branches. Especially if you have collaborators.
> The problematic use of rebase is on pushed branches. Especially if you have collaborators.
Yep. As soon as you have a PR out, and have to address comments, you have a public branch and can't safely rebase it. So you can't roll those new changes in to the "clean" history, If upstream also has changes before your PR gets merged, you'll also have to add a merge commit anyway.
This is a problem of GitHub, not Git. E.g. GitLab preserves comments as well across rebases as any commit changes.
"Don't rebase public branches" is an easy way to say "if someone has built something on top your branch, don't rebase unless you expect them to also rebase." 90% of the time this is not actually harder than merging, though, and still produces a better history and more atomic commits.
At this point I'm even only 99% firm on "never rebase master", as long as release tags are truly immutable.
The more-complicated but still safe use is to rebase your local branch on top of an advanced upstream before pushing. Some people prefer merge for this case, but it is somewhat impure.
The problematic use of rebase is on pushed branches. Especially if you have collaborators.