I can confirm the part about rebase workflow, it really forces you to understand the git model. I sincerely recommend every dev to try it at least once. It also got me into custom power tools for git, like incremental rebase, dual blame, etc.
Too late to edit but I just realized we probably mean very different things by "rebase workflow". I meant making extensive use of Git history editing even on public branches, (with tags serving as backup). I guess the common meaning of "rebase workflow" is just using rebase instead of merge.
Largely we rebase so that all PRs are defacto Fast Forward merges. Rebasing on publicly visible branches (PRs and the like) is common, although rebasing major branches (Master or a release) is not. We're small enough that we can get away with that if we must, though (usually if someone breaks something badly).
Basically, developers rebase all the time on their own branches, and rebase over their target branch (fixing conflicts) so that the PR is fast forward.
Agree on the git model thing, I feel like I have a reasonable idea of how git functions under the hood now, so I can figure out what most operations should do, even if I haven't used them before.
