> I have burned hours upon hours on rebase conflicts over the years.

Hate to say, "You're using it wrong", but if you haven't repeated conflicts rebasing, then your commits are probably just not small enough.

A merge does not magically eliminate any of the conflicts either, you just do them all at once rather than point by point. And the smaller the changeset, the less likely you will have any conflict at all.

Small changes, sorted lists (so parallel additions rarely conflict), allowing trailing commas (again to allow for parallel addition), splitting dependency updates from structural changes (to allow wholesale removing them if they were done separately), ... there's plenty of little changes to how you put together work that make this workflow easier.

Is this true? If the upstream changes some lines of code once, but your branch changes them 5 times in separate commits, iterating on the correct change to those lines, you will have to resolve conflicts 5 times. And 4 of those times you'll be expending effort to merge the correct code from upstream with code you know isn't correct/final on your branch.

Likewise if multiple iterations on those lines were made upstream while your feature branch exists.

Fundamentally expending any effort to find a coherent combination of two pieces of code where one of them you know isn't going to remain is a waste of time.

The only advantage would be if those incremental changes actually make it easier to arrive at the final merge of the last changes on each branch but I'm not sure your above tips really guarantee that. IME it rarely happens.