Promote production-ready commits without merging the entire branch.
Join developers getting comprehensive guides, code examples, optimization tips, and time-saving prompts to accelerate their development workflow.
No spam. Unsubscribe anytime.
When working on larger features, there are moments when part of your work is ready to go live, but the rest of the branch isn’t. You might want to promote specific commits into master without merging the entire feature branch.
That’s exactly what git cherry-pick is for — a surgical way to bring over individual commits. But it comes with nuances: the same commit applied on different ancestry creates new hashes, and this can later cause merge conflicts or duplicated work if not handled carefully.
This article explains the mental model behind cherry-pick, demonstrates it through a real example, and explores what happens later when you merge the full branch. If you're still weighing whether the change should live on a branch or land directly on main, I break down that decision tree in When to Use Git Commits vs Branches as a Solo AI Developer.
In my case, I had a feature branch called feat-multi-step-form. Two commits inside it were complete and ready to go into production:
41f967d322d6029631409b23695486a6b83b5d4a
3767e74d23c900a66b570846a3b2a2e5eda3a3ca
The rest of the branch was still in progress, so merging the whole thing into master would have been premature. I needed only those two commits.
Cherry-picking replays an existing commit’s changes onto your current branch.
To do that safely from the command line:
git checkout master
git pull origin master
git cherry-pick 41f967d322d6029631409b23695486a6b83b5d4a 3767e74d23c900a66b570846a3b2a2e5eda3a3ca
If there are no conflicts, Git creates new commits on master with the same code changes but new hashes. These new commits are independent from their originals on the feature branch.
When you push them:
git push origin master
your master branch now includes the selected work without merging the rest of the feature.
A Git commit isn’t just a bundle of code — it’s a set of changes applied on top of a specific parent commit.
When you cherry-pick, Git takes the diff (the code changes) from one commit and replays it on top of a different parent. Even if the diff looks identical, the context it’s applied to may not be.
That’s why the new commit has a different hash. It’s a new snapshot in history, applied at a different point in time.
You can think of it like copying a note from one notebook into another. The text is the same, but the page number and surrounding notes are different — so it’s technically not the same entry anymore.
Let’s say time passes, and master evolves. Other commits are added, lines shift, and some of the same files you cherry-picked are modified.
Later, you finish the rest of your feature and run:
git checkout master
git merge feat-multi-step-form
Git now tries to reconcile the two histories.
It sees:
feat-multi-step-form: the original commits D and Emaster: new commits D' and E' (the cherry-picked copies)Even though the code might be identical, the ancestry is not. Git can’t assume they’re the same commit, because they were applied on different bases. In most cases, it detects that the changes already exist and skips them. But if the context around those lines has changed, it raises a conflict.
At first glance, this feels paradoxical — if the code is the same, why should a conflict occur?
The answer is that diffs are relative, not absolute.
A commit’s patch says: “replace these lines in this file based on what the file looked like before.” If master’s file has since changed (new lines above, refactors, comments added), Git may not find the exact context it expects.
That’s when it stops and asks for human help. Both versions are valid — one from the old branch, one from the new master — and Git doesn’t assume which one should win.
When a conflict happens, Git performs a three-way merge using:
master)By default, Git doesn’t choose one automatically. It shows both sides and leaves the decision to you.
You can bias the merge process using strategies:
git merge --strategy-option ours
git merge --strategy-option theirs
but it’s generally safer to resolve conflicts manually when dealing with cherry-picked commits, since you often know which version reflects the latest work.
Cherry-picking is best used when:
If sharing the work with another repository is the real goal, consider promoting it via submodules instead — the process is outlined in How to Have Git Repositories Nested Inside Each Other (The Submodules Solution).
It’s less ideal when the branches will continue to evolve and eventually merge, because duplicated commits with different ancestry increase the chance of conflicts later.
Cherry-pick isolated, complete commits. Avoid picking partial work that still depends on later changes in the same branch.
Push cherry-picked commits immediately. Keeping them local increases the chance that master will move and diverge further before they’re shared.
When the feature branch is later merged, rebase or squash it. This keeps history clean and removes the duplicate commits.
If conflicts appear, resolve them by comparing the final code, not commit messages. Git only cares about content, not the order of commits.
Cherry-pick is one of Git’s most powerful tools when used intentionally. It lets you promote selected commits from a feature branch without merging the entire thing — ideal for partial releases, hotfixes, or urgent patches.
But it also introduces a separate line of history, meaning those commits lose their original ancestry. When you eventually merge the full branch, Git may need your help to reconcile them.
Understanding that distinction — that cherry-pick replays a diff onto a new base rather than copying the original commit — is the key to using it safely and predictably.
Thanks, Matija