Yes, but only locally.
You can use git-replace
to replace a commit but retain the ID. This can only be done locally. If you want to push it, you still need to rewrite the commit, and all following commits, with a new ID.
Why not?
Unchanging commit IDs are fundamental to how Git works.
A commit ID represents a checksum of its contents and its parents IDs. This means if you and I both have commits ABC123 we know not only that we have the same commits, but the same history. This helps make Git push and pull so fast, they only need to exchange commit IDs.
A simple way to avoid problems with other collaborators when altering history is to encourage git pull --rebase=merges
. Instead of trying to merge their local changes with the remote, which will cause problems because their local history has diverged from the remote history, it will rewrite their local changes on top of the new remote.
Unlike other rebases, this is safe. It avoids "update merges" which are of no value and only serve to complicate the history.
You can make this the default by setting pull.rebase
to merges
. merges
will try to preserve local merge commits.