I use rebases in my workflow, and I never run git pull. git pull is git fetch + git rebase; and it makes more sense to run those two commands separately. After fetch you can see if there were a lot of changes, and it's more natural to do git rebase --abort and go back to the pre-rebase state

Instead, I do as follows:

• I use my alias git tree, which translates to git log --oneline --graph --decorate --all. There I can see what kind of changes I'm about to rebase on
• If it goes very bad, I rebase not on origin/master but few commits before. In this way, I can fix conflicts more step by step
• if you have to solve conflicts, it makes sense to squash your commits on a branch to an almost final state. If you have 5 commits, it can happen that the same conflict you will have to fix 5 times. If you squash it into 1, same work; but you don't have to repeat it
• as a last resort, you can use git merge origin/master. Git often manages merges ok, and if you care about tree shape (no merge commits, and personally I avoid them) you can just git checkout <the-result-of-merge>; git reset origin/master and create a new commit with just with the file changes

I general, if you work with a team that uses a workflow that uses rebases, you should learn a bit more about git internals & branching. Good materials on that are:

• visual, game-like explanation - https://learngitbranching.js.org/
• the chapter on git internals in Pro Git book: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain