Git Cherry-pick Explained

Git cherry-pick allows you to apply the changes introduced by a specific commit to another branch without merging the entire branch. It is especially useful when you need one particular fix or change but do not want to bring all of the other commits from the source branch.

For example, a bug fix may already exist on a development branch while a production branch needs that same fix immediately. Cherry-pick can copy the change into the production branch without merging all of the unfinished development work.

This makes cherry-pick a useful but specialized Git operation. It gives you precise control over which commits are transferred, but it also creates new commits and can introduce duplicated changes or conflicts if used carelessly.

What Is Git Cherry-pick?

Git cherry-pick takes the changes introduced by one or more existing commits and applies those changes to the current branch. Git then normally creates a new commit containing the applied changes.

git switch main
git cherry-pick abc1234

Here, abc1234 is the commit you want to apply. The commit itself is not moved from its original branch. Instead, Git applies its changes to the current branch and creates a new commit there.

Why Is It Called Cherry-pick?

The name describes the idea of selecting individual changes from a larger set. Instead of taking an entire branch history, you pick particular commits that are useful for the branch you are currently working on.

This differs from operations such as merge and rebase. A merge combines branch histories, while a rebase reapplies a sequence of commits onto a different base. Cherry-pick is more selective: you explicitly choose the commit or commits to apply.

Basic Git Cherry-pick Syntax

git cherry-pick <commit>

The command expects a commit reference. This can be a full commit hash, a shortened hash that uniquely identifies the commit, or another Git revision that resolves to a commit.

git log --oneline

git cherry-pick 7f3a2c1

Using git log --oneline is a convenient way to find the commit hash you want to apply.

What Happens During Cherry-pick?

Git compares the selected commit with its parent to determine which changes that commit introduced. It then attempts to apply those changes to the current HEAD.

If the changes apply cleanly, Git creates a new commit. The new commit contains the applied changes but belongs to the current branch and has a different parent from the original commit.

This distinction is important: cherry-pick does not transfer the original commit object unchanged. It applies the change and creates a new commit.

Cherry-pick vs Merge

If you need an entire feature branch, merging is usually more appropriate. If you need only one or a few specific commits, cherry-pick can provide a more targeted operation.

Cherry-pick vs Rebase

Cherry-pick and rebase both apply existing changes as new commits, but their purposes are different. Rebase normally operates on a sequence of commits belonging to the current branch and changes their base. Cherry-pick lets you select particular commits and apply them elsewhere.

Rebase is therefore commonly associated with maintaining or reorganizing a branch, while cherry-pick is commonly associated with selectively transferring changes between branches.

Finding the Commit to Cherry-pick

Before cherry-picking, you need to identify the commit containing the desired change. Git log is one of the simplest ways to inspect recent history.

git log --oneline --decorate --graph

You can also inspect a particular commit before applying it.

git show 7f3a2c1

Reviewing the commit before cherry-picking is useful because a commit that looks relevant from its message may also depend on other commits or surrounding changes.

Cherry-picking a Single Commit

The most common use case is applying one specific commit to the current branch.

git switch release
git cherry-pick 7f3a2c1

If the commit applies cleanly, Git creates a new commit on release containing the selected change.

Cherry-picking Multiple Commits

You can cherry-pick multiple individual commits in one command by providing several commit references.

git cherry-pick 7f3a2c1 8bc91de 3a17f20

Git processes the selected commits in the order provided. This can be useful when the commits are independent and you want to explicitly control which changes are applied.

Cherry-picking a Range of Commits

Git revision ranges can be used when you want to apply a sequence of commits.

git cherry-pick A^..B

The A^..B notation includes both A and B and the commits between them. Understanding Git revision syntax is important here because a slightly different range can select a different set of commits than intended.

Cherry-pick Without Automatically Committing

The --no-commit option applies the changes without creating the commit automatically.

git cherry-pick --no-commit 7f3a2c1

This can be useful when you want to inspect or modify the resulting changes before creating the final commit. You can then stage the desired files and create your own commit.

git status
git diff
git add .
git commit

The short form -n can also be used for --no-commit.

git cherry-pick -n 7f3a2c1

Cherry-pick and Commit Messages

By default, the new cherry-picked commit uses the message associated with the original commit. The resulting commit is nevertheless a new commit with its own identity.

If the project uses a consistent commit convention, the message can be edited when necessary. This is particularly useful when the context of the change is different on the target branch.

git cherry-pick --edit 7f3a2c1

The --edit option opens the commit message editor before the cherry-pick is completed.

Cherry-pick Conflicts

A cherry-pick conflict occurs when Git cannot apply the selected commit cleanly to the current branch. This can happen when the target branch has changed the same lines or surrounding code in incompatible ways.

git status

Git marks the conflicting files. You need to inspect the conflict markers, determine the correct final content, and then stage the resolved files.

git add path/to/file
git cherry-pick --continue

If several files conflict, resolve each one before continuing. After staging all resolved files, cherry-pick --continue tells Git to proceed with the operation.

Aborting a Cherry-pick

If you determine that the selected commit should not be applied, you can abort the cherry-pick operation.

git cherry-pick --abort

This cancels the current cherry-pick operation and restores the branch to the state it had before the operation began, subject to Git's normal operation and working-tree rules.

Skipping a Problematic Commit

When cherry-picking a sequence of commits, you may determine that one commit should not be applied. Git provides a skip operation for this situation.

git cherry-pick --skip

Skipping should be deliberate. If the next commits depend on the skipped commit, later changes may also fail or produce incorrect results.

Cherry-picking a Merge Commit

Merge commits have multiple parents, so Git needs additional information to determine which parent should be treated as the mainline when extracting the changes.

git cherry-pick -m 1 <merge-commit>

The -m option specifies the parent number to use as the mainline. Choosing the correct parent requires understanding the merge commit and the branch relationship that produced it.

How to Inspect a Merge Commit

git show --summary <merge-commit>
git log --graph --oneline --decorate

These commands can help you determine which branches were involved and which parent should be treated as the mainline.

Cherry-pick and Empty Commits

Sometimes a commit's changes are already present in the target branch. In that situation, applying the commit may result in an empty change set.

Git can stop and ask you how to proceed. Depending on the situation, you may decide to skip the commit or create an intentionally empty commit if preserving the event in history is meaningful for the workflow.

git cherry-pick --skip

Do not assume that an empty cherry-pick indicates an error. It may simply mean that the target branch already contains the effective change.

Cherry-pick for Hotfixes

One of the most common practical uses for cherry-pick is moving a bug fix from one branch to another. For example, a fix may first be implemented on a development branch but also need to be applied to a release branch.

git switch release
git cherry-pick <fix-commit>

This avoids merging unrelated development work into the release branch. After testing the change, the release branch can be deployed according to the project's normal release process.

Cherry-pick for Backporting Fixes

Cherry-pick is also useful for backporting a fix to an older supported branch. A project may have several maintained versions, and a bug fix introduced in the current development line may also be appropriate for an older release.

The fix should still be reviewed for compatibility. A commit that works on the newest branch may depend on APIs, files, or architecture that do not exist in an older release.

Cherry-pick and Duplicate Changes

Because cherry-pick creates a new commit, the same logical change can exist under different commit IDs on different branches. This is not necessarily a problem, but it is important to understand when examining history.

If the original commit is later merged into a branch that already contains the cherry-picked version, Git may recognize that the changes are already represented, but the resulting history can still require careful inspection.

Cherry-pick Does Not Copy Dependencies Automatically

A commit may depend on previous commits. Cherry-picking only the selected commit does not automatically transfer every earlier commit that the change depends on.

For example, a bug fix may reference a function introduced by an earlier commit. Applying only the fix commit to another branch may fail to compile or may produce incorrect behavior because the required earlier change is missing.

Inspecting a Commit's Parents

git show --format=fuller <commit>
git log --parents -1 <commit>

Inspecting the parent relationship can help determine whether a commit is ordinary or a merge commit and can provide additional context before applying it.

Cherry-pick in a Pull Request Workflow

Cherry-pick can be useful when a particular commit from one pull request needs to be applied to another branch or release line. However, teams should document this workflow because selective copying can make it harder to understand why similar changes exist in multiple branches.

A useful practice is to keep commit messages descriptive enough that developers can identify the purpose of a change when it is later cherry-picked or backported.

Cherry-pick and Release Branches

In projects that maintain release branches, cherry-pick can provide a controlled way to move individual fixes into a release without bringing unrelated features along with them.

For this workflow to remain understandable, teams should record which fixes have been backported and verify that each selected commit is compatible with the target release.

Cherry-pick and Git Tags

Tags can help identify the versions from which fixes originate and the releases that contain them. When a project uses tags for releases, inspecting the commits between relevant tags can help identify which fixes need to be transferred.

git log v2.1.0..v2.1.1 --oneline

This can help you review the changes introduced between two versions before deciding which individual commits should be backported.

Cherry-pick and Reverting Changes

If a cherry-picked change needs to be removed after it has been committed and shared, git revert is generally preferable to rewriting the branch history.

git revert <cherry-picked-commit>

The revert creates another commit that reverses the selected commit's changes. This preserves the existing history while documenting the reversal.

How to Undo an Unfinished Cherry-pick

If a cherry-pick is currently paused because of conflicts or another problem, use the operation-specific commands rather than trying to manually reset files without understanding the current state.

git status
git cherry-pick --abort

If the cherry-pick completed successfully and created a commit, undoing it is a different operation. In a shared branch, git revert is usually the safer approach.

Cherry-pick Options Worth Knowing

Common Git Cherry-pick Mistakes

A Safe Cherry-pick Workflow

A deliberate workflow helps prevent accidentally transferring incomplete or incompatible changes.

git status
git switch target-branch
git pull --ff-only

git show <commit>
git cherry-pick <commit>

git status
git diff HEAD^..HEAD
git test

The exact testing command depends on the project. The important part is to inspect the resulting change and verify that the target branch still behaves correctly.

When Not to Use Cherry-pick

Cherry-pick is not a replacement for normal branch integration. If you need most or all of another branch's changes, merging or another branch integration strategy is usually easier to reason about.

• Avoid cherry-picking an entire feature branch commit by commit when a normal merge is appropriate.
• Avoid repeatedly copying the same commits between branches without a documented release strategy.
• Avoid cherry-picking changes that have unresolved dependencies on other commits.
• Avoid using cherry-pick as a substitute for understanding the repository's branching model.
• Avoid applying commits to an incompatible release branch without reviewing the code differences.

Cherry-pick Best Practices

• Keep the working tree clean before starting.
• Inspect the commit with git show before applying it.
• Verify whether the commit depends on earlier changes.
• Use precise commit references rather than guessing hashes.
• Apply only the commits that are actually needed.
• Resolve conflicts carefully and review the final diff.
• Run relevant tests after cherry-picking.
• Document important backports and hotfix transfers.
• Use git revert rather than rewriting shared history when a completed cherry-pick needs to be undone.
• Be especially careful with merge commits and the -m option.

Cherry-pick and Good Commit Structure

Cherry-pick works best when commits represent focused, understandable changes. A commit that mixes unrelated refactoring, formatting, dependency changes, and a bug fix is harder to transfer safely than a focused bug-fix commit.

This is one reason clear commit messages and logically separated changes matter. A developer looking through history should be able to determine what a commit does and whether it is appropriate for another branch.

Conventional Commits can provide additional structure when a project uses them. Consistent prefixes such as fix, feat, and refactor can make commit history easier to search and review.

A Practical Example

Imagine a project with main and release branches. A security-related bug has been fixed on main, but the release branch does not contain the fix. The development branch also contains several unrelated features that are not ready for release.

git switch main
git log --oneline

git show 91ab42e

git switch release
git pull --ff-only

git cherry-pick 91ab42e

Only the selected commit's changes are applied to release. After the cherry-pick, the result should be reviewed and tested. If the fix depends on another commit that release does not contain, those dependencies must be handled separately.

Cherry-pick and Conflict Resolution Checklist

• Run git status before starting.
• Inspect the selected commit and its parents.
• Check whether related commits are required.
• Apply the commit with git cherry-pick.
• Use git status if Git reports a conflict.
• Resolve every conflicting file deliberately.
• Stage resolved files.
• Continue with git cherry-pick --continue.
• Run tests and inspect the final diff.
• Abort with git cherry-pick --abort if the operation should not continue.

Helpful Git Workflow Tools

Several types of developer tools can support a Git workflow around cherry-pick. A Git commit generator can help create focused commit messages, while a Conventional Commit generator can help maintain a consistent commit format.

A Git branch name generator can help create consistent names for feature, release, hotfix, or backport branches. Release notes and changelog generators can then help summarize changes included in a release.

Conclusion

Git cherry-pick is a precise way to transfer selected changes between branches. Instead of integrating an entire branch, you choose one or more commits and apply their changes to the current branch.

This makes cherry-pick particularly useful for hotfixes, backports, release branches, and other situations where only a specific change is needed. At the same time, cherry-picking creates new commits and does not automatically bring along dependencies, so each selected commit should be inspected before it is applied.

Used carefully, cherry-pick gives you fine-grained control over Git history and allows targeted changes to move between branches without importing unrelated work. The key is to keep commits focused, understand their dependencies, resolve conflicts deliberately, and follow the repository's branching and release conventions.