When I rebase and a conflict arises, the conflicted file looks like this:
<<<<<<< c50c817dad7008a3760241084de2b83fd4f84288
it was on master 456
=======
it was on master 123
>>>>>>> branch - set up README conflict
Sometimes other people don't make such great commit messages, so I might wind up with something like this:
<<<<<<< c50c817dad7008a3760241084de2b83fd4f84288
it was on master 456
=======
it was on master 123
>>>>>>> fixed stuff
The problem with this is that if there are more than one "fixed stuff" commits, I'll have trouble finding the exact commit. Is there a way I can make git always use SHA hashes instead of commit messages?
Unfortunately, no.
Well, on the other hand: yes, sort of: use a detached HEAD and cherry pick commits manually, by ID so that git doesn't have a name it can substitute-in. That defeats much of the purpose of rebase though (rebase automates the cherry-picking, plus the branch-name update at the end).
You shouldn't need to do this for two reasons, though. The one you can't control is that people should not be using crappy commit messages. :-) The one you can use is that when rebase stops with a conflict, HEAD and CHERRY_PICK_HEAD identify the SHA-1s of the two conflicting commits. See the git cherry-pick documentation for details.
(I also recommend setting merge.conflictstyle to diff3, which lets you see the base version. It's not as necessary for rebase/cherry-pick as for full merges, but I like it.)