Git commit’s id is a hash of its contents and its history, and becomes a unique id for a specific commit. Even if it contains the same change, as the parent would be different, it’ll have a different id.
“git cherry-pick” takes a commit from somewhere else, and “play it back” where you are right now. Git will build a new commit with a different hash, as the parents are different, though the contents are the same. One thing to note is that git hash is branch agnostic. in Git, an branch is simply “a lightweight movable pointer to one of these commits” (from git branching)
The other day, I rebuilt a release branch for release (of course!). I had to fix one issue, so committed the fix to the release branch. I made a few other changes and revoked the change, as they were not really necessary. Now I wanted to cheery-pick the commit for the fix.
I did git log.
C:\Users\andrew.chaa\Documents\Projects\PopOpen [release]> git log commit 36bfde24c821f36f84c6ec88c796ae6edac17286 Author: andrewchaa <> Date: Wed May 13 15:45:34 2015 +0100 the version is updated to 0.8.6 commit 8c803f203a03b9bd11faca7a754e0f1f4c8ab1b3 Author: andrewchaa <> Date: Tue May 5 11:23:34 2015 +0100 Added Logging. No more fixed time looping. Use MainWindowTitle and check if the found window has the same fil
I know the commit hash, 8c803f203a03b9bd11faca7a754e0f1f4c8ab1b3.
git checkout master git cherry-pick 8c803f203a03b9bd11faca7a754e0f1f4c8ab1b3
Then the change is on top of the last commit on the master branch. I can push the change to the server.