Cherry-pick

Cherry-pick applies the changes from one existing commit onto another branch as a new commit.

It is a way to copy a specific change without merging the entire branch that change originally came from.

When cherry-pick is useful

Cherry-pick is useful when you want one particular commit, but not the full line of development behind it.

For example, you might cherry-pick when:

• A bug fix from one branch also needs to be applied to another branch.
• You want to copy a small, isolated change into a release branch.
• A teammate made one commit you need, but the rest of their branch is not ready to merge.

How cherry-pick differs from merge

A merge combines the history of whole branches.

A cherry-pick is narrower. It takes the change introduced by one specific commit and applies that change again on your current branch.

That means:

• Merge is branch-oriented.
• Cherry-pick is commit-oriented.

If you only need one or two specific commits, cherry-pick can be simpler than merging a whole branch.

Cherry-pick creates a new commit

Even though cherry-pick uses an existing commit as its source, the result on your current branch is a new commit with its own identity.

That matters because the original commit and the cherry-picked commit are not literally the same history entry. They may represent the same logical change, but they are separate commits in Git's history.

Conflict risk

Cherry-pick can cause conflicts if the target branch has changed too much from the context where the original commit was created.

For example, Git may struggle if:

• The same lines were already edited differently.
• The surrounding code no longer matches.
• The target branch does not contain earlier changes that the commit expected.

In that case, you resolve the conflict much like you would during a merge or rebase.

A practical caution

Cherry-pick is powerful, but it can also lead to duplicate or overlapping history if used carelessly.

If the same logical change is merged later through the original branch as well, the repository may end up with two separate commits representing similar work. That is not always wrong, but it is something to keep in mind when choosing between cherry-pick and merge.