Git Cherry-Pick

Apply selected commits in a new context, resolve cherry-pick conflicts safely, and keep source identity in the new message.

Select a change without merging a branch

What cherry-pick copies—and what it does not

A normal commit represents a snapshot plus metadata and a parent. Cherry-pick computes the selected commit’s change relative to its parent, applies that change to the current branch, and creates a new commit.

Use cherry-pick for a narrow transfer

Inspect source, destination, and patch first

git status
git branch --show-current
git log --oneline --decorate --graph --all
git show --format=fuller --stat <source-commit>
git show <source-commit>
git branch --contains <source-commit>
git diff <source-commit>^ <source-commit>

1. 01
   Confirm destination

   HEAD must name the branch that should receive the new commit.

2. 02
   Require clean state

   Preserve unrelated index and working-tree changes before applying a patch.

3. 03
   Read source intent

   Inspect parent, full patch, message, tests, and dependent commits—not only the subject line.

4. 04
   Test the baseline

   Know whether the destination already fails before attributing failures to the pick.

Apply one traceable commit

git status
git show --stat --oneline <source-commit>
git show --format=fuller <source-commit>

# Apply the patch as a new commit and record its origin:
git cherry-pick -x <source-commit>

git show --stat --oneline HEAD
git status

With a clean application, -x appends a “cherry picked from commit …” line to the new message. This is especially useful for public backports because it connects two different commit IDs without pretending they are the same object.

Resolve a cherry-pick conflict in its new context

A patch that applied on the source parent may conflict or behave differently on the destination. Inspect the stopped commit and resolve for the destination branch’s supported behavior.

git status
git show CHERRY_PICK_HEAD
git diff --name-only --diff-filter=U

# Edit, test, and stage the intended destination result
git add <resolved-paths>
git diff --cached
git diff --cached --check
git cherry-pick --continue

# Or restore the complete pre-operation state
git cherry-pick --abort

git cherry-pick --skip omits the current commit in a multi-commit sequence. Use it only after proving the change is redundant or intentionally excluded.

Pick multiple commits with explicit order

# Explicit objects are applied left to right:
git cherry-pick -x <commit-one> <commit-two> <commit-three>

# Commits after A through B, excluding A:
git cherry-pick -x A..B

# Include A through B:
git cherry-pick -x A^..B

Range notation selects a revision set; the order and topology may not match a simplistic visual reading in complex graphs. Preview the exact set with git log --reverse --topo-order A..B and prefer explicit IDs when auditability matters.

Combine selected patches before one commit

git cherry-pick --no-commit <commit-one> <commit-two>
git status
git diff --cached

# Adjust only when required by the destination, then test
git commit -m "Backport parser boundary fixes"

--no-commit applies changes to the index and working tree without creating each original commit. The final commit no longer has automatic one-to-one provenance, so document all source IDs and explain why combining them is correct.

Treat cherry-picking a merge commit as exceptional

A merge has multiple parents, so Git needs a mainline parent to determine which combined change should be replayed.

git show --no-patch --pretty=raw <merge-commit>
git diff <merge-commit>^1 <merge-commit>
git diff <merge-commit>^2 <merge-commit>

# Only after identifying the correct parent semantics:
git cherry-pick -m 1 <merge-commit>

Prove the transferred change

1. PATCH
   Intended difference

   Compare source and destination patches; explain context adjustments.

2. TRACE
   Source recorded

   The backport message identifies the original commit and reason for transfer.

3. BEHAVIOR
   Destination tests pass

   Exercise both the defect and compatibility promises of the target branch.

4. STATE
   Focused clean result

   No unrelated paths, unresolved entries, or working changes remain.

git show --format=fuller --stat HEAD
git diff HEAD^ HEAD
git diff <source-commit>^ <source-commit>
git status

When the transferred commit is the release you want to name, continue in Git Tags. This lesson stops at a proven cherry-pick.

Guided practice: backport a focused fix

1. 01
   Create two release lines

   In a disposable repository, let main advance while a release branch remains on an older compatible API.

2. 02
   Author a focused fix

   Commit a tested parser correction on main and identify every dependency.

3. 03
   Backport with provenance

   Pick with -x, adapt one intentional conflict, and test release compatibility.

4. 04
   Prove the destination commit

   Compare source and destination patches, confirm tests, and keep the working tree focused.

Independent lab: audited patch transfer

1. Create a disposable repository with main and release/1.3 histories, plus one transferable fix, one required prerequisite, and one unrelated feature.
2. Prove why the fix and prerequisite belong in the backport while the feature does not.
3. Use --no-commit to combine the two required patches into one release commit whose message records both source IDs.
4. Produce an audit note containing source commits, destination patch, and test evidence.

Common cherry-pick mistakes

Lesson review

You can now transfer a focused change while preserving its origin, handle destination-specific conflicts, and prove the resulting commit. Git tags, taught next, name that verified object without turning cherry-pick into a release button.

• I inspect source patch, dependencies, destination branch, and baseline before cherry-picking.
• I use -x or explicit source IDs when backport provenance matters.
• I understand multi-commit ranges, no-commit mode, and merge mainline selection.
• I prove the transferred change with patch, tests, and a focused working tree.