I think rebase is generally the correct approach here. If you've done your own work on top of their old changes, rebase your work on top of their new changes.
That's possible but it requires a bunch of manual tracking and results in wasted/duplicate effort with people resolving the same conflicts multiple times.
This to me is a sign that some commits should be squashed, because it implies the same lines have changed multiple times in the commits that are ahead of the remote branch. It's worth doing the rebase interactively and squashing them up.
If you find yourself fixing the same rebase conflicts over and over again, because you for some reason need to work on conflicting changes simultaneously (which is of course best avoided for other reasons), use "git rerere".
I don't trust rerere, it can do major damage in cases like where a commit was reverted. And you still get multiple people solving the same conflicts, so even if each person only resolves each conflict once it's still wasteful compared to a merge workflow.