git cherry-pick lets you grab a specific commit from one branch and apply it to another.
Let’s say you’re working on a feature branch, feature-x, and you’ve made a commit with a crucial bugfix. Meanwhile, your main branch has diverged, and you need that bugfix there now, without merging the entire feature-x branch.
Here’s the scenario:
# On branch main
git log --oneline
f1a2b3c (HEAD -> main) Merge branch 'some-other-feature'
4d5e6f7 Add new component
a1b2c3d Initial commit
# Switch to feature-x
git checkout feature-x
git log --oneline
e8f9g0h (HEAD -> feature-x) Fix critical bug in login
c2d3e4f Implement user authentication
a1b2c3d Initial commit
You want commit e8f9g0h on your main branch.
# Switch back to main
git checkout main
# Cherry-pick the commit
git cherry-pick e8f9g0h
Git will now try to apply the changes introduced by e8f9g0h onto your current main branch. If successful, it creates a new commit on main with the same changes and commit message, but with a different commit hash.
# On branch main
git log --oneline
a9b8c7d (HEAD -> main) Fix critical bug in login # This is the new commit from cherry-pick
f1a2b3c Merge branch 'some-other-feature'
4d5e6f7 Add new component
a1b2c3d Initial commit
The beauty is that main now has the bugfix, and feature-x remains untouched. You can continue developing feature-x independently.
What if you want to apply multiple commits? You can provide a range. For example, to apply commits c2d3e4f and e8f9g0h from feature-x to main:
git checkout main
git cherry-pick c2d3e4f..e8f9g0h
This applies c2d3e4f and then e8f9g0h in order. Note the .. syntax: it means "all commits reachable from e8f9g0h but not reachable from c2d3e4f." If you want to include c2d3e4f itself, you’d use c2d3e4f^..e8f9g0h (the ^ means "parent of"). A more common way to grab a sequence is git cherry-pick <older-commit>^ <newer-commit>, which picks them in sequence.
Sometimes, cherry-picking isn’t a clean application. If the target branch has diverged significantly, or if the commit you’re picking modifies code that has also been changed on the target branch, you’ll hit a conflict.
# Example of a conflict during cherry-pick
git cherry-pick e8f9g0h
error: could not apply e8f9g0h... Fix critical bug in login
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git cherry-pick --continue'
hint: you can abort the cherry-pick with 'git cherry-pick --abort'
To resolve this, you’ll manually edit the conflicted files. Look for the <<<<<<<, =======, and >>>>>>> markers. Once you’ve made the code changes to reconcile the conflicting versions, you stage the files:
git add path/to/conflicted/file.js
Then, you tell Git to continue the cherry-pick process:
git cherry-pick --continue
Git will then create the new commit. If you decide the cherry-pick is a bad idea altogether, you can abort it:
git cherry-pick --abort
This will return your branch to its state before you started the cherry-pick.
A common pitfall is cherry-picking a merge commit. git cherry-pick is designed for changesets (the diff introduced by a commit), not for merging strategies. If you try to cherry-pick a merge commit, Git will usually complain or attempt to create a commit that represents the changes introduced by the merge itself, which is rarely what you want. To apply changes from a merged branch, you typically want to merge the branch or cherry-pick the individual commits from it.
The git cherry-pick command can also take options like -n (or --no-commit) which applies the changes from the commit to your working directory and index, but doesn’t create a new commit. This is useful if you want to cherry-pick several commits and then combine them into a single commit yourself, or if you want to make further modifications before committing.
Another useful option is -x, which appends a line like (cherry picked from commit <original-commit-hash>) to the new commit message. This is invaluable for tracking where the commit originally came from, especially in larger projects where commits might be cherry-picked multiple times.
Consider the main branch having a commit M1 and feature-x having commits F1 and F2. If you git checkout main and then git cherry-pick F1 F2, you’ll get two new commits on main, say M1' and M2', which are the same changes as F1 and F2 but have different commit hashes. This is a form of "duplicate" commit history, which can be confusing if not managed carefully. It’s generally preferred to merge branches when possible, as it preserves the history more cleanly. Cherry-picking is best reserved for specific, targeted application of changes, like hotfixes or when you absolutely need a single commit from another line of development.
The next step after successfully cherry-picking a commit that was originally part of a larger feature is often to clean up the original branch or to reconsider your branching strategy.