I hate rebases because they create multiple hashes for the same logical commit. It confuses the crap out of me sometimes. Also, they tend to involve more manual processing, and thus human error, then merges.
> I hate rebases because they create multiple hashes for the same logical commit
Some of those commits may have changed (either the commit message or the diff itself). There's a git command called range-diff[1] that was added recently that allows you to diff between rebases.
> Also, they tend to involve more manual processing, and thus human error, then merges.
Before actually pushing up the rebased branch, you run a diff against the upstream tracking branch to see if any inadvertent changes were introduced. For example:
git diff @{u}..
And use the range-diff command to see the difference between the upstream tracking branch and your locally rebased branch.
This. I've had to spend time fixing history after a Jr engineer did a bad rebase. After a few episodes of that I decided I had to either stop hiring Jr engineers, have them always supervised by a Sr engineer, or stop rebasing.
> I've had to spend time fixing history after a Jr engineer did a bad rebase.
I tell people to run git log -p --reverse origin/master.. on the rebased branch and check that everything works before they push up their branch to the remote. I also tell them to run git rebase --exec "linting-command" --exec "unit-test-command" --exec "integration-test-command" and make sure that tests pass for every single commit. If they don't, then they spend time fixing it until they do.
