Git Cherry-Pick: Copy a Commit to Another Branch

Why it exists

Sometimes you need a specific change from one branch, but you can't merge the entire branch. For example, a single bug fix is on your develop branch, but you need it on a stable release branch immediately, without all the other new, unstable features. Cherry-pick solves this by isolating and reapplying just that one commit's changes.

The mental model

Think of git cherry-pick as a targeted copy-and-paste operation for commits. Instead of merging branches, which brings over an entire history, you are selecting a single "fruit" (a commit) from one branch's "tree" and placing it onto another. The result is a new commit on the target branch that contains the exact same code changes as the original, but with a new commit hash and history.

How it works

When you run git cherry-pick <commit-hash>, Git finds the specified commit and calculates the patch (the diff) it introduced. It then tries to apply this patch to your current HEAD. This requires your working tree to be clean. If the application is clean, Git creates a new commit with the same message as the original. If there are conflicts, the process pauses, marks the conflicting files with <<<<<<< and >>>>>>>, and waits for you to resolve them manually before continuing (--continue) or stopping (--abort).

When to use it

The primary use case is backporting fixes. Imagine a critical security patch is committed to your main branch. You can cherry-pick that single commit onto older, supported release branches. It's also useful for grabbing a small improvement from a feature branch without merging the whole incomplete feature. Use the -x flag to automatically add a "(cherry picked from commit...)" line to the message, which is crucial for tracking origins on public branches.

When not to use it

Avoid using cherry-pick as your main workflow instead of merging. If you find yourself cherry-picking many commits from a feature branch, you should probably just merge the branch. Overuse creates a messy, duplicated history that is hard to reason about and can cause complex merge conflicts later when the original and cherry-picked branches are eventually merged. It breaks the clear lineage that git merge or git rebase provides.

One canonical example

To apply a bug fix from the develop branch to your current release branch, first find the commit hash of the fix (e.g., a1b2c3d) using git log develop. Then, on the release branch, run git cherry-pick a1b2c3d. This creates a new commit on release with the same changes and message as the original commit on develop.