git cherry-pick takes the changes from one or more existing commits, and applies them as new commits on your current branch. It’s the standard way to backport a bug fix from main to a release branch, or to rescue a commit made on the wrong branch, without merging everything else.

Basic usage

git switch release/1.8
git cherry-pick a1b2c3d
git push

The new commit has the same changes and message, but a different hash (different parent).

Find the commit hash with git log --oneline main, or in your Git host’s web UI.

Record where it came from: -x

git cherry-pick -x a1b2c3d

This appends (cherry picked from commit a1b2c3d…) to the message, which is very useful when tracing fixes across release branches.

Several commits

git cherry-pick a1b2c3d e4f5a6b               # specific commits, applied in order
git cherry-pick a1b2c3d^..e4f5a6b             # a range, including a1b2c3d
git cherry-pick main~3..main                  # the last 3 commits of main

Pick in chronological order (oldest first), so dependent changes apply cleanly.

Handling conflicts

If a commit doesn’t apply cleanly, Git stops:

git status                      # shows conflicted files
# edit files, resolve conflict markers
git add <files>
git cherry-pick --continue
# or give up on this pick:
git cherry-pick --abort         # back to before the cherry-pick
git cherry-pick --skip          # skip this commit, continue with the rest

Options worth knowing

Option Effect
-x Add “cherry picked from” to the message
-n / --no-commit Apply changes without committing (combine several picks into one commit)
-e Edit the commit message
-m 1 Pick a merge commit, using parent 1 as the base
--signoff Add a Signed-off-by line

Common scenarios

Backport a fix to a supported release:

git switch release/1.8
git cherry-pick -x <fix-commit>
git tag v1.8.4 && git push --follow-tags

See Git tags and releases.

Committed on the wrong branch:

git switch correct-branch
git cherry-pick <commit>
git switch wrong-branch
git reset --hard HEAD~1          # only if not pushed yet

See undo the last commit.

When not to cherry-pick

  • Moving many commits between long-lived branches: you end up with duplicate commits (different hashes, same changes) that later conflict, or appear twice. Merge or rebase instead. See git merge vs rebase.
  • Picking a commit that depends on earlier unpicked commits: it may apply, but break the build. Run the tests.
  • As a substitute for a branching strategy: if you cherry-pick constantly between environment branches, use one main branch and promote artifacts instead. See Git branching strategies.

Check before you pick

git log --oneline --cherry-pick --right-only release/1.8...main   # commits on main not yet in release/1.8 (patch-equivalent ones hidden)
git branch --contains <commit>                                    # which branches already have it (same hash)

Quick reference

Task Command
Pick one git cherry-pick <hash>
Traceable git cherry-pick -x <hash>
Range git cherry-pick A^..B
Without committing git cherry-pick -n <hash>
After conflicts git add … → git cherry-pick --continue
Cancel git cherry-pick --abort

Related: git stash and Git commands cheat sheet.

  • Git
  • Command Line
  • DevOps