I think a lot of the fear of rebasing comes from not fully grokking what it does, and not rebasing often enough.
My workflow typically involves rebasing my local branches on master every time I switch a branch or start a work session, so typically conflicts that need to be resolved are very clear and small things (e.g. someone else adds a case to a switch statement in the same place your branch does).
The biggest benefit to this that I see is that your diffs are then much more clear in what they're doing, and you have the option to update the commit message to reflect the conflict resolution if required.
That said, if you have a big feature branch and try to rebase it after a month vacation, you're gonna have a bad time.
Daily local rebase on master is really the only acceptable use I know for rebasing. It's not just after a month of vacation, but simply when your local branch has a lot of commits, that rebasing can become very painful, as you may have to resolve the same conflict over and over and over again. That must be the circle of hell where programmers end up.
Basically you'd have to rebase after every single commit. That would keep it the most painless, I guess. But I can also just do a single merge and I'm done.
My workflow typically involves rebasing my local branches on master every time I switch a branch or start a work session, so typically conflicts that need to be resolved are very clear and small things (e.g. someone else adds a case to a switch statement in the same place your branch does).
The biggest benefit to this that I see is that your diffs are then much more clear in what they're doing, and you have the option to update the commit message to reflect the conflict resolution if required.
That said, if you have a big feature branch and try to rebase it after a month vacation, you're gonna have a bad time.