Introduction

Git users often want to move one commit from one branch to another without merging unrelated work. git cherry-pick does exactly that, but it creates a new commit object. Because of how Git computes commit IDs, the new commit cannot keep the original SHA.

This is not a tooling limitation or a missing flag. It is a direct consequence of Git’s content-addressed model, where the hash is derived from the commit’s actual contents and context.

Why the SHA Changes

A Git commit hash is calculated from the full commit object, not only from the diff. That object includes:

• The tree snapshot
• The parent commit or commits
• Author and committer metadata
• Timestamps
• The commit message

When you cherry-pick, the parent commit is almost always different because you are applying the change onto another branch. A different parent means a different commit object, and a different commit object means a different SHA.

Even if you copied the same message, author, and patch text, the commit would still hash differently once the parent chain changed.

What Cherry-Pick Actually Preserves

Cherry-pick preserves the patch content as closely as possible. Conceptually, Git computes the change introduced by the original commit and tries to replay that change on top of your current branch tip.

That means the important thing being preserved is the effect of the commit, not its identity.

Here is the usual workflow:

git switch release-branch
git cherry-pick 4f6c2d1

If you want Git to record where the change came from, use the -x option:

git switch release-branch
git cherry-pick -x 4f6c2d1

That appends a reference to the original commit hash in the new commit message, which is often the most practical substitute for preserving the SHA itself.

Better Options When Identity Matters

If you truly need the original commit hash to remain part of branch history, you need to move the existing commit object into the target branch rather than recreate it.

That usually means one of these strategies:

Merge or Rebase the Branch

If the original commit already exists on another branch, merging or rebasing may bring that exact commit into the target branch history.

git switch release-branch
git merge feature-branch

This preserves commit identity because the existing commit object is reused instead of being regenerated.

Attach Metadata Instead of Reusing the SHA

If the workflow only needs traceability, add the original hash to the new commit message or use Git notes.

git notes add -m "Backported from 4f6c2d1"

This keeps an explicit relationship between the original and backported commits without pretending they are the same object.

Compare by Patch Identity

Sometimes you do not care about object identity at all. You only care whether two commits represent the same logical change. In that case, use git patch-id or git cherry style comparisons.

git show 4f6c2d1 | git patch-id --stable

Patch identity is useful for auditing backports because it focuses on the diff rather than the SHA.

Practical Backport Workflow

A good backport process usually looks like this:

1. Cherry-pick with -x.
2. Resolve conflicts carefully.
3. Run tests on the target branch.
4. Keep the original SHA in the message or release notes.

This gives you reproducibility and traceability without fighting Git’s object model.

If your organization relies on external ticket links or deployment dashboards, the -x convention is especially helpful because it makes the source commit visible in plain history.

Common Pitfalls

The most common mistake is assuming a commit hash identifies only a patch. In Git, it identifies the full commit object, including ancestry. That is why two commits with the same visible code change can still have different SHAs.

Another pitfall is trying to force the old hash by rewriting public history. Even if you manipulate metadata aggressively, once the parent chain differs, the hash differs. Rewriting published history to chase a specific SHA usually creates more operational risk than value.

Conflicts are another source of confusion. If the cherry-pick requires manual resolution, the resulting commit is no longer even the same patch in a strict sense. In that case, recording the origin with -x becomes even more important.

Finally, do not use SHA equality as the only way to detect backports. Branch structure, rebases, and cherry-picks make that assumption unreliable.

Summary

• A cherry-picked commit cannot keep the original SHA because the commit object changes.
• Git hashes cover parentage and metadata, not just the diff.
• Use git cherry-pick -x when you need a durable reference to the source commit.
• Merge or rebase if you must preserve the exact original commit object in history.
• For audits and backports, patch identity and explicit metadata are usually more useful than SHA equality.