cherry-pick a commit and keep original SHA code

According to your comments to other answers I think you simply want to reset to some remote commit. You can use git reset --hard <SHA> to do this. WARNING: This will discard all of your (uncommitted) changes in the working directory and all commits you did in this branch will no longer be accessible.

If this is not what you want (or you are not sure) please describe more clearly what you did and what you want to do or what you are trying to accomplish.

Go into interactive rebase ("git rebase -i") and paste a new entry at the end with the exact revision you want to prepend to your HEAD.

Example:

Open an interactive rebase session:

$ git rebase -i HEAD~4

The screen now shows [something like] this:

pick efdd0ece Linked how to make a pull requests in README
pick 790a3be8 adjust pytest pins to fix testing infra
pick 5bb90d8f drop 3.4 support
pick 839dc8ba v2.22.0
pick b97fb61a Print the type of the password instead of the password itself

Your current HEAD is the last entry. Add a new entry to the bottom (just "pick" and your revision; no description necessary) with the exact revision that you want to prepend:

pick efdd0ece Linked how to make a pull requests in README
pick 790a3be8 adjust pytest pins to fix testing infra
pick 5bb90d8f drop 3.4 support
pick 839dc8ba v2.22.0
pick b97fb61a Print the type of the password instead of the password itself
pick 2a173c2a6491aae0772640ba7946a08315d18eb8

Save and close. That exact revision will now be your HEAD:

$ git log --oneline | head -n 6
2a173c2a Some commit
b97fb61a Print the type of the password instead of the password itself
839dc8ba v2.22.0
5bb90d8f drop 3.4 support
790a3be8 adjust pytest pins to fix testing infra
efdd0ece Linked how to make a pull requests in README

As mentioned in other answers, you still have to follow the rules. This works in only the very narrow case where you have the exact same branch, parents, and committer (such as with a code-review-centric process where you have a bunch of commits queued up somewhere, where the developers can push them up and bring them down without necessarily submitting them into the repository first); really only when the timestamps are the only thing that might have changed. In this case, you can force the identical revision in order to force the timestamps to be unchanged.

In most other cases, the parent will usually be different, and, this alone, means that your dream of forcing a certain revision will be dead. Git will always fix-up the revision to be correct if any of the non-timestamp factors are different.

A git SHA hash is computed from different pieces of information:

1. The tree it refers to; basically, the current content of the repository in the branch in which the commit appears.
2. The SHA of the parent commit(s).
3. The commit message.
4. The author information: name, email and timestamp.
5. The committer information: name, email and timestamp.

Even if you edit a cherry-picked commit so that the tree, the commit message, the author and committer information are exactly the same, the SHA of the parent commit (or commits, if dealing with merge commits) will be always different. So, you will not be able to generate the same SHA hash after a cherry-pick (unless you find a SHA collision ;) ).

The SHA commit hash is made of from the state of the repository, using the whole history up to the point of the commit (branches not included). This means that you cannot keep the original hash on cherry-picking unless the whole history is the same, and in that case cherry-picking would make no sense.