You're right that rebasing changes the commit hash, since part of the hash consists of the parent commit and the commit time, and both change during rebase. However, this is okay as git can handle merging and rebasing makes the history cleaner as it avoids merge-commits which can be very ugly. Rebasing can cause problems though if branches are used instead of tags for versioning since branches are moving targets, unlike tags which are static. It looks like both tags and branches have the name 1.4.1 in the repo on github, so just deleting the branches, and using the tags instead once they're finalized would probably clear things up.