Ideally I’m working on a short lived branch that only I’m working on in which case I do a rebase from origin/master where I also touch up the history in case there are any “forgot x in the previous commit” type of commits before doing a merge request. I won’t rebase code someone else might have pulled, and I’ll quit rebasing if I get any non-trivial conflicts .

I use rebase only to clean up some commit messages, squash commits, etc. - essentially to clean up feature branches I wrote. But never rebase to ‘move’ my branch as if it originated from a different commit, because I don’t know necessarily know what changes have been introduced on the other branch (typically main/master), so rebasing on that would leave my commits in a state that they were never tested in, possibly broken / with unintended sideeffects. If I need changes from the other (main) branch in my feature branch (because of feature dependencies, or to fix merge conflicts), I merge it into my branch and can be sure that the commits created before that merge still behave the way they did before that merge - because they were not changed; this can’t be said for rebasing.

The cases where you can use git pull --rebase have high overlap with the cases where git rebase is sane.

The important thing is when to avoid doing git push --force (almost always; if your remote is a personal fork you theoretically could just create an infinite number of similar branch names for your rebases). Though there are edge cases involving local/SSH clones.

Please never rebase after you open a pull request. It breaks the iterative workflow of code reviews – it makes it hard to see if issues brought up in comments were addressed or not.