change ids are more analogous to commit messages than branches, eg suppose that in a feature branch you have a "Delete deprecated classes" commit; in git there is a clear idea of "cloning" this commit (eg rebase, cherrypicks, maybe reverts) and the common sense that the new commit inherits the same commit message. Change ids are the same thing but in hex id form that can be created for every new commit/stash/index.
They allow for example to identify all the clones of a commit and they allow to give stable identities across rebases eg suppose you rebase a typo at the beginning of a feature branch without change ids a reviewer sees n new unrelated commits while with change ids it is possible to clearly identify which commits where changed/added/removed since the previous review iteration.
> suppose you rebase a typo at the beginning of a feature branch without change ids a reviewer sees n new unrelated commits while with change ids it is possible to clearly identify which commits where changed/added/removed since the previous review iteration.
A rebase can introduce change to a commit in cases such as handling conflicts or squashing.
Also, a commit already retains it's commit message after rebasing.
> A rebase can introduce change to a commit in cases such as handling conflicts or squashing.
and with change ids you can quickly separate commits that changed from commit that did not.
> Also, a commit already retains it's commit message after rebasing.
but commit message are not ids, there is no command for checking out a commit by its message, nor any sense that commit with the same message are somehow functionally related
They allow for example to identify all the clones of a commit and they allow to give stable identities across rebases eg suppose you rebase a typo at the beginning of a feature branch without change ids a reviewer sees n new unrelated commits while with change ids it is possible to clearly identify which commits where changed/added/removed since the previous review iteration.