git cherry-pick

# 1) Simplest — apply one commit
git checkout main
git cherry-pick abc1234
# Creates a NEW commit on main with the same change; original SHA preserved in the message.

# 2) Range of commits (exclusive..inclusive)
git cherry-pick abc1234..def5678
# All commits from abc1234 (exclusive) to def5678 (inclusive).

# Include the FIRST too:
git cherry-pick abc1234^..def5678

# 3) Without committing — stage only
git cherry-pick --no-commit abc1234
# Or shorthand:
git cherry-pick -n abc1234
# Apply, then 'git commit' yourself with a custom message.

# 4) Edit the commit message
git cherry-pick --edit abc1234

# 5) Cherry-pick a MERGE commit — pick the parent side
git cherry-pick -m 1 merge-sha   # use parent 1 (usually the main branch)
git cherry-pick -m 2 merge-sha   # use parent 2 (usually the feature branch)

# Without -m, picking a merge fails; you must say which side to take.

# 6) Sign-off + author preservation
git cherry-pick -s abc1234        # add Signed-off-by
git cherry-pick -x abc1234        # add '(cherry picked from commit abc1234)' note

# 7) Conflicts — resolve, continue
git cherry-pick abc1234
# CONFLICT (content): Merge conflict in src/auth.ts

# Edit files, remove markers, then:
git add src/auth.ts
git cherry-pick --continue

# Or skip this commit:
git cherry-pick --skip

# Or abort:
git cherry-pick --abort

# 8) Real-world: hotfix on release branch + main
# Apply the fix on hotfix/1.2.x:
git checkout hotfix/1.2.x
git commit -am 'fix: validation error in payment endpoint'
FIX_SHA=$(git rev-parse HEAD)
git push

# Then cherry-pick onto main:
git checkout main
git cherry-pick $FIX_SHA
git push

# Pattern: develop on the highest priority branch; cherry-pick down/up.

# 9) Cherry-pick from another remote
git fetch upstream
git cherry-pick upstream/release/1.2.x~3..upstream/release/1.2.x

# 10) Find commits to cherry-pick
git log --oneline main..hotfix/1.2.x   # commits on hotfix not yet on main
git cherry main hotfix/1.2.x           # quick view of commits to potentially port

# 11) Difference vs merge / rebase
# • merge — combines BRANCH HISTORIES; preserves the structure
# • rebase — replays commits, rewriting your branch's parents
# • cherry-pick — copies INDIVIDUAL commits; you pick which ones
#
# Cherry-pick is the surgical tool; merge is bulk move; rebase is history rewrite.

# 12) Avoid pick-conflict whack-a-mole
# Long-running release branches accumulate divergence. Each cherry-pick may conflict.
# Mitigations:
#   • Keep release branches short-lived
#   • Cherry-pick early — sooner conflicts are smaller
#   • Use rerere — remembers previous resolutions
git config --global rerere.enabled true

# 13) Detect already-cherry-picked commits
# git cherry shows commits NOT YET on the target by 'patch equivalence':
git cherry -v main hotfix/1.2.x
# + abc1234 fix: blah         (new, not on main)
# - def5678 chore: bump dep   (already on main)

# 14) When NOT to cherry-pick
# • Whole feature branch ready to land — merge or rebase instead
# • Commits that depend on earlier ones not yet ported → cherry-pick the dependency too
# • Restructuring history — rebase -i is the right tool
# • You want to preserve the merge bubble — use merge

# 15) Common bugs
# • Cherry-picking a commit that depends on uncommitted-here changes → conflict storm
# • Forgetting -m on merge commit → 'is a merge but no -m option was given'
# • Cherry-pick chains creating duplicate work — use -x to track ORIGIN
# • Cherry-picking the SAME commit twice → no-op (when content identical) or conflict (when target evolved)
# • Conflicts left half-resolved + 'git cherry-pick --continue' without staging → fails
# • Cherry-picking from a force-pushed branch → orphan commits; the SHA may not exist
# • Cherry-pick across major refactors — every line conflicts; rewrite the fix manually
# • Forgot to push after cherry-pick → main stays behind

git cherry-pick 4d5e6f7      # apply one commit
git cherry-pick A^..B        # range of commits