git cherry-pick Command: Apply Commits from Another Branch

Sometimes the change you need already exists, just on the wrong branch. A hotfix lands on main when it also needs to go to a release branch, or one useful commit is buried in a feature branch you do not want to merge wholesale. git cherry-pick copies the effect of a specific commit onto your current branch without touching anything else.

How to Use git cherry-pick:

The syntax is:

bash<br>git cherry-pick [OPTIONS] COMMIT...<br>COMMIT can be a hash, a branch reference, or a range. git cherry-pick replays the changes introduced by the selected commit on top of your current branch and creates a new commit. The new commit has a different hash even when the file changes are identical — because the parent commit is different.

Find the commit you want with git log –oneline on the source branch:

bash<br>git log --oneline feature/auth

Switch to the target branch first, then run cherry-pick:

bash<br>git switch main<br>git cherry-pick a3f1c92

Git applies the change from a3f1c92 and creates a new commit 9b2d4f1. The subject line carries over, but the hash is new.

Cherry-Pick Multiple Commits and Ranges
Non-consecutive commits pass the hashes in the order you want Git to apply them. Git creates a separate commit for each:

bash<br>git cherry-pick a3f1c92 d8b22e1

Consecutive range. The caret determines whether the starting commit is included:

git cherry-pick a3f1c92^..7c4e003 # includes a3f1c92 through 7c4e003<br>git cherry-pick a3f1c92..7c4e003 # excludes a3f1c92; starts from the commit after it<br>The caret (^) means "include this commit". Without it, the starting commit is excluded and Git applies only the commits that come after it.

Useful Options: –no-commit, -x, and Merge Commits
–no-commit (or -n) applies the changes to your working tree and staging area without creating a commit. Use this when you want to combine several picks into one commit or review the result before finalizing:

git cherry-pick --no-commit a3f1c92<br>git commit -m "Backport auth null-check fix"<br>-x records the source commit hash in the new commit message automatically:

git cherry-pick -x a3f1c92

Commit message will include:

This is a good habit for backports. It creates a clear audit trail and makes it easy to prove that a fix on a release branch came from a reviewed commit on another branch.

Merge commits need the -m option to tell Git which parent to use as the main line:

git cherry-pick -m 1 MERGE_COMMIT_HASH

-m 1 uses the first parent the branch that received the merge. -m 2 uses the second. If you are not sure which parent is which, check the history first with git log –oneline –graph. Cherry-picking merge commits is more error-prone than cherry-picking regular commits. If the goal is to bring over an entire merged feature, a normal merge is usually the cleaner option.

Resolve Conflicts and Follow a Safe Backport Workflow
When the target branch has conflicting changes in the same area of code, Git stops and reports the problem:

error: could not apply a3f1c92… Fix null pointer in auth handler
hint: After resolving the conflicts, run “git cherry-pick –continue”
Open the conflicted file, resolve the conflict markers, stage the result, and continue:

git add src/auth.js<br>git cherry-pick --continue

To cancel the operation and return the branch to its exact state before the cherry-pick started:

git cherry-pick --abort

Safe backport workflow. When cherry-picking onto a release or maintenance branch, follow this sequence:

git switch release/1.4<br>git pull --ff-only # ensure the branch is up to date first<br>git cherry-pick -x a3f1c92 # pick with -x for traceability<br>git status # review before pushing

git pull –ff-only fails deliberately if the branch has diverged from its upstream that is a useful safety check. If the picked commit depends on refactors or APIs that are not present on the target branch, stop there. Either cherry-pick the prerequisite commits first or recreate the fix manually.

When to Use (and Avoid) git cherry-pick

Good fits:
Backporting a bug fix from main to a release branch
Recovering one useful commit from an abandoned feature branch
Moving a fix that was committed to the wrong branch
Pulling a reviewed change into a hotfix branch without merging unrelated work
Avoid it when the commit depends on earlier commits, shared refactors, or schema changes that are missing from the target branch. When the target branch needs the full context of the source branch, a merge or rebase is the better option.

Use git cherry-pick HASH for a single fix, A^..B for a consecutive range, -x for any backport you want to trace, and –abort if the operation goes sideways. Leave a comment below if you run into any issues.