Cherry-pick: what it is, how to perform it, and Git commands

What is cherry-pick in Git

Cherry-pick is the git cherry-pick command that takes changes from an existing commit and applies them as a new commit in the current branch. The original commit stays in place in its own branch, while a copy of the changes is created in the target branch. The command is useful when you need to transfer a specific fix without moving an entire branch.

Syntax: git cherry-pick <commit-hash>. Git analyzes the diff of the specified commit against its parent and applies that diff to the current branch. If multiple files are changed, they are all transferred together. The command also accepts ranges: git cherry-pick A..B — all commits from A to B, excluding A.

Flags extend its capabilities: -n (--no-commit) applies changes to the working directory and index without creating a commit — useful when you need to combine changes from several commits into one. The -x flag adds a line (cherry picked from commit ...) to the commit message, making it easier to track the origin of changes in history.

# Cherry-pick a single commit by hash
git cherry-pick a1b2c3d

# Cherry-pick multiple commits (sequentially)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# Cherry-pick without auto-commit
git cherry-pick -n a1b2c3d

# Flag -x adds reference to original commit
git cherry-pick -x a1b2c3d

When to use cherry-pick

The main scenario is transferring fixes between release branches. Imagine: a critical bug was found and fixed in develop. The release branch release/v2.1 is already separated and also contains this bug. Merging the entire develop into release would bring a lot of unfinished code, while cherry-picking the single fix commit is a safe and precise solution.

The second scenario is reverting changes with subsequent restoration. If a commit was reverted via git revert and later it turns out the revert was a mistake — cherry-picking the reverted commit restores the changes. This is more correct than reverting a revert because it does not create repeated conflicts.

The third scenario is combining commits from different feature branches into one test branch for integration testing. Instead of merging several unfinished branches (with incomplete code), you can select only the ready commits from each and test how they work together.

• Bugfixes — transfer a fix from develop to release without unfinished code.
• Hotfix — apply a fix from a hotfix branch to main and develop simultaneously.
• Undoing a mistaken revert — cherry-pick the reverted commit to restore changes.
• Testing — collect selected commits from different branches for integration testing.

Cherry-pick vs rebase and merge

Cherry-pick differs from rebase and merge in that it works at the level of individual commits rather than entire branches. While rebase transfers all commits of a branch and merge combines two branches, cherry-pick selects only the needed ones. This makes it a more precise tool, but also more manual.

Another difference is authorship. During cherry-pick, Git by default preserves the author of the original commit, but the committer becomes the current user. The commit message can track the origin via the -x flag. During rebase, both author and committer become the current user with a new hash.

Performance: cherry-picking a single commit is faster than merging two branches with many commits. But if you need to transfer dozens of commits, it is better to create a temporary branch and perform a rebase — this will be more efficient and will not require specifying dozens of hashes.

Transferring multiple commits

Multiple commits can be transferred with a single command by listing their hashes separated by spaces: git cherry-pick A B C. Git applies commits sequentially in the specified order. If any commit causes a conflict, cherry-pick pauses, and the developer must resolve the conflict, then continue with git cherry-pick --continue.

Commit range: git cherry-pick A..B (all commits after A up to B, excluding A) and git cherry-pick A^..B (all commits from A inclusive to B). Ranges are convenient when you need to transfer all commits from one branch without the parent relationship — for example, when moving a completed feature from an old branch to a new one.

The --strategy flag determines how Git applies changes. By default, the recursive strategy is used, but you can specify ours or theirs to automatically pick a conflict side. The --mainline flag is used when cherry-picking a merge commit — it specifies the parent number (1 or 2) against which the diff is computed.

# Cherry-pick commit range
git cherry-pick develop~5..develop~2

# Cherry-pick merge commit (specify parent)
git cherry-pick -m 1 m9n0o1p

# Use theirs strategy
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# Continue after conflict resolution
git cherry-pick --continue

Conflicts during cherry-pick

Conflicts during cherry-pick occur when changes from the transferred commit affect the same lines that were changed in the target branch. Git pauses execution, marks the conflicting files, and waits for resolution. In the status, such files are shown as both modified.

Steps to resolve a conflict: open the conflicting file, find the conflict markers (<<<<<<<, =======, >>>>>>>), edit the content, remove the markers, run git add for the resolved files, and execute git cherry-pick --continue. If the conflict cannot be resolved — git cherry-pick --abort cancels the entire cherry-pick, returning the branch to its original state.

A common issue: the commit already contains changes equivalent to existing ones. In this case, Git reports “nothing to commit” or “empty commit” when attempting cherry-pick. The --keep-redundant-commits and --empty=keep flags force Git to create an empty commit to preserve the sequence, while --skip allows skipping such a commit.

# Conflict during cherry-pick — stop
git cherry-pick a1b2c3d
# error: could not apply a1b2c3d... commit message

# Resolve conflict → add to index
git add src/conflicted_file.swift
git cherry-pick --continue

# Skip empty commit (already applied)
git cherry-pick --skip

# Full abort
git cherry-pick --abort

Cherry-pick best practices

First rule: always verify that the commit being transferred is self-contained. If commit A depends on changes in commit B that is not being transferred, cherry-picking A may break the build. Before cherry-picking, it is useful to check which files the commit changed via git show --stat <hash>.

Second rule: document cherry-pick operations. Use the -x flag so that the commit message retains a reference to the original commit. This will help during subsequent history analysis to understand where the change came from. Without -x, a cherry-pick looks like a regular commit, and its origin can only be determined via git log --graph.

Third rule: avoid cherry-pick between branches that have diverged too much. If a lot of time has passed since the commit was created and the codebase has significantly changed, conflicts will be numerous and complex. In such cases, it is better to re-implement the fix in the target branch — it will take less time than resolving dozens of conflicts.

• Cherry-pick only self-contained commits without external dependencies.
• The -x flag is mandatory for documenting the commit origin in the message.
• Avoid cherry-picking old commits with significant codebase divergence.
• CI/CD verify the build after cherry-pick: a conflict might not have occurred, but the code may not compile.
• PR comment when creating a pull request, indicate which commits were transferred via cherry-pick.