Cherry-pick — what it is, mechanism and application in Git

What is Cherry-pick?

Cherry-pick is a Git command that copies changes from a specified commit and applies them as a new commit in the current branch. The name comes from the metaphor of "cherry picking": a developer selects only the commits they need, ignoring the rest.

Unlike Merge, cherry-pick does not create a merge commit and does not require a full branch merge. Unlike Rebase, cherry-pick does not transfer a sequence of commits — only the specified ones. This makes cherry-pick an ideal tool for targeted transfer of fixes.

According to Atlassian, 2025, cherry-pick is used by 47% of teams working with multiple release branches simultaneously. Cherry-pick is especially in demand in mobile development, where multiple versions of an application (LTS releases) are maintained simultaneously and fixes need to be transferred between them.

Transfer Mechanism

When performing a cherry-pick, Git calculates the diff between the specified commit and its parent, then applies this diff to the current branch. If the changes are applied without conflicts — Git creates a new commit with the same message but a new SHA. If there is a conflict — cherry-pick pauses for manual resolution.

How Cherry-pick Works

Syntax of cherry-pick is simple: specify the hash of the commit to transfer. Git copies the changes to the current branch as a new commit. Transferring multiple commits at once and entire ranges is supported.

# Cherry-pick a single commit to the current branch
git cherry-pick a1b2c3d4

# Cherry-pick multiple commits
git cherry-pick a1b2c3d4 e5f6g7h8

# Cherry-pick a range of commits (from a1b2 to f9e8, excluding a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

After executing cherry-pick, the current branch gets a new commit with the changes from the source. The commit message is copied from the source by default, but can be modified with the -n flag (do not create a commit) or --edit (edit the message).

Example of Transferring a Fix

Consider a typical scenario: a critical bug is found and fixed in develop, which also exists in the release branch release/v2.0. Only this fix needs to be transferred, without merging the entire develop into the release branch.

# Find the commit hash with the fix in develop
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Switch to the release branch
git checkout release/v2.0

# Apply the fix
git cherry-pick a1b2c3d4

# If a conflict occurs — resolve and continue
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

The -x flag adds a reference to the original SHA in the commit message: "(cherry picked from commit a1b2c3d4)". This makes it easier to trace where the commit was transferred from. It is recommended to use -x in all scenarios except temporary drafts.

Working with Conflicts

In case of a conflict, cherry-pick behaves like merge: Git stops and marks the conflicting files. The developer resolves the conflict, runs git add and executes git cherry-pick --continue. To cancel — git cherry-pick --abort. The --strategy flag allows specifying a merge strategy (e.g., recursive with options).

# Resolving a conflict during cherry-pick
# Git shows conflicting files
git status

# Resolve manually, then:
git add allowed_file.kt
git cherry-pick --continue

# Or abort cherry-pick:
git cherry-pick --abort

When to Use Cherry-pick

Cherry-pick is optimal in scenarios where a targeted transfer of changes is needed without merging entire branches. Let's look at five main cases where cherry-pick becomes the best choice.

• Hotfix transfer — a fix is found in develop, but needs to be applied to the release branch (release/v2.0). Cherry-pick transfers only the fix commit without affecting unfinished features from develop
• Backport to older versions — a fix for the current version needs to be transferred to an LTS release. Instead of merging the entire current codebase, cherry-pick selects only the needed commits
• Undoing a commit in the wrong branch — if a commit was made to the wrong branch, cherry-pick transfers it to the correct one, and the original commit is reverted
• Documentation transfer — changes to README or configuration files that should be in all branches are convenient to transfer via cherry-pick
• Selective application — from a prototype branch, only one successful commit needs to be taken without transferring the entire prototype to main development

For mobile development, cherry-pick is critically important when supporting multiple versions of an application. For example, if a bug is found in version 3.2 already released on Google Play, and develop contains code for version 4.0 — cherry-pick allows transferring the fix to the v3.x branch without merging all breaking changes. This is especially relevant for projects where two or more major versions with different APIs and dependencies are maintained simultaneously.

Practical example: a mobile application has a crash during Google Sign-In authentication on Android 12. The fix is made in develop and passes code review. However, the current release branch v2.5 is already in beta testing. Cherry-picking the fix commit from develop to release/v2.5 allows including the fix in the upcoming release without transferring other changes that are not yet ready for release.

When using cherry-pick in mobile projects, it is important to consider dependencies: if the fix affects files that were changed in develop after the release branch diverged, cherry-pick may bring an incomplete set of changes. In such cases, you need to verify that all related changes are also transferred, otherwise the application may fail to build or work incorrectly. Always check the build after cherry-pick before pushing changes to the shared branch.

Cherry-pick vs Merge vs Rebase

Three main tools for integrating changes in Git — merge, rebase and cherry-pick — solve different tasks. The choice depends on how much change needs to be transferred and how the history should look.

Merge — when you need to merge two branches entirely and preserve branching information. Rebase — when you need to update a personal branch to the latest state with a clean history. Cherry-pick — when you need only one commit or several selected commits.

In practice, these tools are combined: a feature is developed with periodic rebase onto develop, then merged via --no-ff merge, and when a fix needs to be transferred to another branch, cherry-pick is used. Each tool solves its own task at its own stage.

Risks and Limitations of Cherry-pick

Cherry-pick is a useful but potentially dangerous tool when used incorrectly or excessively. The main risks are related to commit duplication, loss of context, and conflicts during subsequent merges.

• Commit duplication — if the same commit later enters the branch via merge, Git will create a second commit identical in changes. This pollutes the history and complicates git bisect
• Loss of context — cherry-pick transfers the diff but does not transfer information about parent commits and dependencies. If cherry-pick applied commit A without commit B on which A depended, logical errors may occur
• Merge conflicts — after cherry-pick, during a full branch merge, Git may see the same changes twice and create conflicts that could have been avoided with a normal merge
• Lack of traceability — without the -x flag, it is impossible to know that a commit was transferred from another branch. When searching for the origin of a change, a developer may spend hours figuring out where the commit came from

Recommendations for risk minimization: always use the -x flag to indicate the original SHA, document the reason for cherry-pick in the commit message, and when possible, use merge instead of cherry-pick when the context allows. If cherry-picks become numerous — consider branch restructuring.

Automated Checks for Cherry-pick

CI pipelines should consider cherry-pick as a separate scenario. It is recommended to set up an automated check: when a cherry-pick commit is created, CI verifies that the changed files match the expected set and runs tests for affected modules. This reduces the risk of regression when transferring changes between branches.