Indeed, from my observations people using rebase are usually working solo or in very small teams, or just like spending insane amounts of time fixing their broken code.
The typical effective way to work with Git is to develop on master while running "git pull --rebase" regularly, and before you commit. Prefer to build up a feature as one commit, with "git commit --amend" or "git commit --fixup". Since you pull and rebase regularly, your code is closely in sync with all shipped changes, and if there are any conflicts you get to resolve them in small incremental pieces. When your change passes CR, push it.
The result is a simple, clear, linear commit history with a minimum of effort spent on branching and merging fuss. The fuss is rarely worth it. This model works for quite large teams. After a certain size, it might be better to split the package into several rather than add branching/merging complexity.
You can make as many commits as you need on your feature branch. When you're done with the feature, you do `git pull --rebase origin master` (or whatever the main branch is) and squash your commits into one (or a few -- when it makes sense) using `git rebase -i`.
I know the workflow of rebasing a feature branch into one commit on master, but that doesn't sound like what Pyxl101 was talking about, regarding the use of "git commit --amend" and "git commit --fixup".
Rebasing is safe as long as you only do it to commits you haven't shared yet. Of course the risk is that if rebasing becomes your default, there's a risk you might also do it on a commit you already have shared.
As any time traveler knows, you need to be careful when you rewrite history.
The result is a simple, clear, linear commit history with a minimum of effort spent on branching and merging fuss. The fuss is rarely worth it. This model works for quite large teams. After a certain size, it might be better to split the package into several rather than add branching/merging complexity.