Gotcha: Git cherry-pick creates duplicate commits

Cherry-picking commits between branches creates duplicate commits that cause confusion and merge conflicts later.

Cherry-pick duplication issues and solutions:

# The problem:
# Branch A: commit abc123 "Fix login bug"
# You cherry-pick abc123 to Branch B
# Branch B now has: commit def456 "Fix login bug" (different hash!)
# When A and B are merged -> duplicate changes, possible conflicts

# Solution 1: Record cherry-pick (helps git track it)
git cherry-pick -x abc123
# Adds "(cherry picked from commit abc123)" to message
# Git still doesn't track this automatically, but humans can

# Solution 2: Use merge instead of cherry-pick when possible
git merge feature-branch
# Merge preserves the commit relationship

# Solution 3: Cherry-pick then squash on merge
# When merging the source branch later, squash to avoid duplication
git merge --squash feature-branch

# Solution 4: Rebase before merge (eliminates duplicates)
# If both branches will be merged to main:
git rebase main feature-branch
# Rebased commits have same content, git detects the duplication

# Check for cherry-picked commits
git log --cherry-pick --oneline main...feature-branch
# Shows commits NOT equivalent between branches

# List commits that exist on one branch but not the other
git cherry -v main feature-branch
# + = commit only on feature-branch
# - = equivalent commit exists on main

Best practices:

• Use cherry-pick sparingly (hotfixes to release branches)
• Prefer merge/rebase for normal workflow
• Always use -x flag when cherry-picking
• Clean up with squash merge when branches converge

Cherry-pick copies the changes but creates a new commit with a different hash. Git doesn't know the commits are related, leading to duplicate patches and conflicts at merge time.

Git branching workflows