Cherry-pick borrows; rerere remembers
Sometimes you want one commit from another branch without merging the whole branch. git cherry-pick <hash> takes the changes introduced by that commit and applies them on top of your current branch as a new commit. The new commit has a different hash from the source — it is a copy, not a move. Use cases: backporting a bug fix from main to a release branch, lifting a single useful commit out of an experiment branch you are otherwise abandoning, propagating a fix across long-lived parallel branches.
Cherry-pick can take a range — git cherry-pick A..B applies every commit after A through B in order. Conflicts pause the operation like a merge or rebase; resolve, git add, git cherry-pick --continue. --abort rewinds. -x appends "(cherry picked from commit <hash>)" to the message — invaluable when you cherry-pick across branches and want the audit trail to point at the source.
git rerere ("reuse recorded resolution") is the unsung hero of repos with long-running parallel branches. Once enabled, every conflict you resolve is recorded by Git. The next time the same conflict appears — same hunk, same content on both sides — Git resolves it automatically using your recorded answer. The labor savings on a maintenance branch that periodically merges with main are dramatic. Enable globally with git config --global rerere.enabled true and forget about it; the savings accumulate silently.
The combination shines in maintenance work. Suppose you backport ten fixes from main to a release branch. Without rerere, every cherry-pick that touches lines main has since refactored produces a fresh manual conflict. With rerere on, you resolve each pattern once; subsequent cherry-picks involving the same conflict pattern auto-resolve. git rerere status shows what is recorded. git rerere clear wipes the cache when stored resolutions become wrong.