I use interactive rebases to clean up the history of messy branches so they can be reviewed commit by commit, with each commit representing one logical unit or type of change.

Mind you, getting those wrong is a quick way to making commits disappear into nothingness. Still useful if you're careful. (Or you can just create a second temporary branch you can fall back onto of you need up your first once.)

Well, rebase allows you to resolve the same conflict ten times in a row instead of doing it once. How cool is that?

Only before you collaborate with anyone else. After that, don't ever use rebase, or they'll get an error, and will have to overwrite their local history with the one you've rewritten.

The way I structure my commits, it is usually (but not always) easier and more reliable for me to replay my commits one at a time on top of the main branch and see how each relatively small change needs to be adapted in isolation--running the full test suite at each step to verify that my changes were correct--than to be presented with a slew of changes all at once that result from marrying all of my changes with all of the changes made to the main branch at once. So I generally start by attempting a rebase and fall back to a merge if that ends up creating more problems than it solves.