Gotcha: Git cherry-pick creates a new commit with a different hash

Cherry-picking a commit creates a copy with a different hash, potentially leading to duplicate commits if the branch is later merged.

Understand cherry-pick implications:

# Cherry-pick creates a NEW commit:
git cherry-pick abc1234 # Creates a copy with different hash

# The original (abc1234) and the copy (def5678) have:
# - Same changes (diff)
# - Different hash (different parents, timestamp)
# - Git sees them as DIFFERENT commits

# Problem: Merging later may show 'already applied' conflicts
# Branch A: ... -> abc1234 -> ...
# Branch B: ... -> def5678 (cherry-picked copy) -> ...
# Merging A into B: potential conflicts on same changes

# Prevention:
# 1. Prefer merging branches over cherry-picking
# 2. If you must cherry-pick, use -x to record the source:
git cherry-pick -x abc1234
# Adds '(cherry picked from commit abc1234)' to message

# 3. For hotfixes, cherry-pick TO main, then merge main back:
git checkout main
git cherry-pick abc1234 # Apply hotfix
git checkout develop
git merge main # Merge includes the fix

# Cherry-pick a range:
git cherry-pick abc1234..def5678 # Exclusive start
git cherry-pick abc1234^..def5678 # Inclusive start

# Cherry-pick without committing:
git cherry-pick --no-commit abc1234 # Stage changes only

# Abort if conflicts:
git cherry-pick --abort