Git Cherry-Pick

What Is Git Cherry-Pick?

git cherry-pick is a Git command that lets you take one or more specific commits from any branch, and apply them as new commits on top of your current branch. Instead of merging an entire branch, you select exactly the commits you need, and replay them wherever you are.

Think of it as "picking a cherry" from the commit tree—you pluck a single commit (or a few) and place it onto another branch, preserving the author, timestamp, and message (unless you choose to modify them). The commit will have a new SHA-1 hash because it becomes a new commit object with a different parent, but the changes introduced are identical.

Why Cherry-Pick Matters

🚀 Deploy your AI agent in 10 minutes

Managed Hermes hosting. Zero DevOps. 100M tokens/mo included.

Try it free →

Cherry-picking is a powerful tool for selective integration. It solves several common development workflow problems:

Hotfixing across releases: You fix a critical bug in the development branch and need to apply just that fix to a stable release branch without merging all other ongoing changes.
Recovering lost commits: If a commit was accidentally made on the wrong branch, you can cherry-pick it into the correct branch and then revert or reset the original.
Partial feature backporting: You want to bring a small, self-contained feature improvement from a newer version into an older maintenance branch without dragging along unrelated commits.
Splitting work: After working on a messy feature branch, you can cherry-pick only the clean, well-tested commits into the main branch, leaving the experimental ones behind.
Review and testing: You can pull individual commits from a long pull request branch to test or review them in isolation.

Using cherry-pick avoids the "all or nothing" nature of merges, giving you fine-grained control over what goes into your branch.

How to Use Git Cherry-Pick

Cherry-Picking a Single Commit

The simplest form picks one commit by its hash:

git cherry-pick <commit-hash>

For example, suppose you have two branches: main and feature. The feature branch has a commit a1b2c3d that you want on main. First, switch to main:

git checkout main
git cherry-pick a1b2c3d

Git will apply the changes from a1b2c3d and create a new commit. You'll see output like:

[main 5e6f7a8] Fix login validation error
 Date: Mon Apr 7 10:30:00 2025 +0200
 1 file changed, 5 insertions(+), 2 deletions(-)

The new commit on main has a different hash but the same commit message (unless you edit it).

Cherry-Picking Multiple Commits

You can cherry-pick a range of commits or a list of individual hashes:

# Pick a linear range (inclusive) from commit A to commit B, where A is older
git cherry-pick A..B

# Or specify multiple separate commits
git cherry-pick hash1 hash2 hash3

The range syntax A..B includes commits reachable from B but not from A. Typically you want the commits between two points on a branch. For example, to bring the last three commits from feature into main:

git checkout main
# Assuming the feature branch has commits: d4e5f6a, 7b8c9d0, e1f2g3h (oldest to newest)
git cherry-pick d4e5f6a..e1f2g3h

Git will apply each commit in order. If any commit fails due to conflicts, the whole process pauses and waits for you to resolve the conflict.

Handling Conflicts During Cherry-Pick

Conflicts happen when the changes in the cherry-picked commit clash with the current state of your branch. Git will pause mid-process and mark the conflicted files. You'll see:

error: could not apply a1b2c3d... Fix login validation
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 commit'

To resolve:

Edit the conflicted files and remove the conflict markers (<<<<<<, =======, >>>>>>).
Stage the resolved files: git add <file>.
Continue the cherry-pick: git cherry-pick --continue.

If you want to abort the entire cherry-pick and go back to the pre-cherry-pick state, use:

git cherry-pick --abort

To skip a commit that can’t be applied and move on to the next (only valid when picking multiple commits), use:

git cherry-pick --skip

Useful Options

Cherry-pick comes with several options that tailor its behavior:

-x – Append a line to the commit message that says "(cherry picked from commit
)". This helps trace the origin of the commit later.
```
git cherry-pick -x a1b2c3d
```
-n / --no-commit – Apply the changes to your working directory and staging area, but don't create a new commit. Useful to combine multiple cherry-picked changes into one commit.
```
git cherry-pick -n a1b2c3d
git cherry-pick -n b4c5d6e
git commit -m "Combine two hotfixes"
```
--signoff – Add a Signed-off-by line at the end of the commit message (used in projects that require a Developer Certificate of Origin).
```
git cherry-pick --signoff a1b2c3d
```
-e / --edit – Open the commit message editor before creating the commit, allowing you to change the message.
```
git cherry-pick -e a1b2c3d
```
--strategy – Use a specific merge strategy (like recursive, resolve, ours) for resolving conflicts.
```
git cherry-pick --strategy=recursive -X theirs a1b2c3d
```

Best Practices and Pitfalls

When to Use Cherry-Pick

Cherry-pick shines in targeted, low-risk situations:

Applying a single hotfix to multiple release branches.
Porting a small, well-isolated commit between long-running branches.
Recovering a commit from a deleted branch (as long as you still have its hash).
Building a release branch by picking specific stable commits from a development branch.

When to Avoid Cherry-Pick

Overusing cherry-pick can lead to a tangled history and duplicate commits (same change, different hashes) that make future merges confusing. Avoid cherry-pick when:

The change depends on earlier commits that you aren't picking – you risk missing context and introducing subtle bugs.
You need to bring over a whole feature or a series of tightly coupled commits – a merge (or rebase) is cleaner and preserves the relationship.
You are cherry-picking in both directions (from branch A to B and later from B to A) – this often creates duplicate commits that Git may not handle gracefully during subsequent merges.
The commit introduces large structural changes that conflict heavily with the target branch – the manual resolution effort can be high, and a merge might be more appropriate.

Keeping History Clean

Cherry-picking creates a new commit with a different hash. If you later merge the branch that originally contained the commit, Git will see the same change introduced twice. Usually Git’s merge logic can detect duplicate patches and skip them, but it’s not foolproof. To minimize confusion:

Use the -x flag to record the original commit hash, which helps future archaeologists understand where the change came from.
Communicate with your team when cherry-picking is happening, so nobody accidentally merges the same change again.
Consider rebasing the target branch if the cherry-picked commit belongs to a series that should eventually be fully integrated – rebase rewrites history and avoids duplicates.

Cherry-Pick and Branching Workflows

In Gitflow or similar workflows, cherry-pick is often the recommended way to bring hotfixes from main (or a dedicated hotfix branch) back into develop. For example:

# On the hotfix branch, commit the fix
git checkout hotfix/login-fix
# ... fix bug, commit as a1b2c3d
git checkout develop
git cherry-pick -x a1b2c3d
git checkout main
git cherry-pick -x a1b2c3d

This keeps the hotfix isolated and applies it exactly where needed without merging the entire hotfix branch prematurely.

Testing Cherry-Picks

Always test the result of a cherry-pick. The applied changes may interact differently with the target branch’s codebase. Run your test suite and consider doing the cherry-pick on a temporary branch first:

git checkout -b test-cherry-pick main
git cherry-pick a1b2c3d
# Run tests, if all good:
git checkout main
git cherry-pick a1b2c3d
git branch -D test-cherry-pick

Automating Cherry-Pick in Scripts

Cherry-pick can be scripted for repetitive tasks. A common pattern is to cherry-pick all commits from a specific author or with a certain keyword in the message. For example, using git log and a loop:

# Pick all commits by author "Jane" from feature-branch into main
git checkout main
commits=$(git log feature-branch --author="Jane" --format="%H" --reverse)
for hash in $commits; do
  git cherry-pick $hash
done

Be careful: if any cherry-pick fails, the script may need to handle the conflict or abort gracefully. A production script would check exit codes and use --continue or --abort as needed.

Conclusion

git cherry-pick is an essential precision tool in any developer's Git toolbox. It empowers you to surgically move commits across branches, enabling hotfix propagation, commit recovery, and selective feature integration. By understanding its basic usage, conflict resolution, and the rich set of options like -x and -n, you can handle complex version control scenarios with confidence.

However, with great power comes responsibility. Overuse can muddy your project history and create duplicate commits that confuse merges. Stick to cherry-picking isolated, self-contained changes, always record the original commit hash when possible, and test the results thoroughly. When you need to integrate a whole feature or a chain of dependent commits, favor merging or rebasing instead. Used wisely, cherry-pick keeps your branches lean and your history meaningful.