A rebase always creates a new hash, because the commit hash is a hash over the contents of the commit. This contents include, among others, the parent commit(s) and the time of committing (which in case of a rebase will be different than the time of authoring).
"git rebase" doesn't create a new hash if there's no change as a result of the rebase. But GitHub's PR rebase button always creates a new hash even if there is no reason to. (Its PR merge button does not do this; it will merge a one-commit PR without creating a new commit).
To add to the inconsistencies, GitHub doesn't sign the new commit when using the rebase button so it doesn't show up with the green "verified" icon - even if there was no need for a new commit anyway. Yet when using the merge button it does the opposite - if it doesn't need a new commit, your signed PR commit is merged to the main branch and shows as verified, and if it does need a new commit GitHub signs it (if the PR commit was signed) so it still says "verified" (even though it's really GitHub's key that was used, not the author's).
For this reason, when I merge PRs I avoid the GitHub UI, and use "git rebase -S" locally followed by "git push". This does what the PR rebase button should do.
