Git is usually about managing streams of history. You merge rivers of code together. But sometimes, you don’t want the whole river. You just want one specific fish.
That’s git cherry-pick.
Introduction
The command git cherry-pick <commit-hash> takes the changes from a single specific commit and applies them to your current branch as a new commit.
It’s highly useful in specific scenarios:
- Hotfixes: You fixed a bug in
dev, and you need that same fix inprodright now, but you can’t mergedevyet because it has unfinished features. - Mistakes: You committed to the wrong branch.
How to use it
Let’s say you are on main and you want a commit abc1234 that exists on feature-branch.
- Find the hash:
git log feature-branch # verify that abc1234 is the one you want - Execute the pick:
git checkout main git cherry-pick abc1234
Git will take the diff from that commit and try to apply it to main. If successful, it automatically creates a commit.
Handling Conflicts
Just like a merge, cherry-picking can result in conflicts if the code has diverged too much.
If this happens, Git will pause.
- Open the conflicted files and resolve the
<<<<markers. git add <file>git cherry-pick --continue
When NOT to use it
Don’t use cherry-picking as a substitute for proper merging. If you find yourself cherry-picking 10 commits in a row, you are probably doing it wrong—you should likely be merging or rebasing.
Cherry-picking creates duplicate commits (different IDs, same content). If you later merge the branches, Git is usually smart enough to figure it out, but it creates a messy history. Use it sparingly.
Conclusion
Git Cherry-pick is a precision tool. You won’t use it every day, but when you need to perform surgery on your repository—extracting a critical fix without bringing in unwanted baggage—it is the only tool for the job.
Did you like this post? Please let me know if you have any comments or suggestions.
Git posts that might be interesting for you