Somewhere down the row, a neighboring branch has grown a tree full of commits. You don't need the whole tree — just a few ripe fixes for your basket. Learn git cherry-pick the way an orchardist learns their trees: by hand, one careful fruit at a time.
The feature/login tree has grown eight commits. Only three glowing cherries belong in your hotfix basket. Drag each glowing cherry down into the basket — leave the plain green ones on the branch. That's the heart of git cherry-pick <hash>: you take a single commit's changes, not the entire branch.
Commit C extends the null-check that commit B introduced. Pick C before B and the fruit won't fit the basket — a conflict, just like real git cherry-pick would raise when a commit depends on context that isn't there yet.
Three feature trees are ripening in parallel: feature/auth, feature/ui, feature/payments. Your hotfix basket needs exactly one bug-fix cherry from each — not the surrounding feature work. This mirrors a real backport: shipping urgent fixes to a release branch without dragging in unfinished features.
Sometimes a critical bug is fixed across multiple commits, buried inside a massive feature branch. You need to extract exactly the 4 fixes in the correct order: core → api → ui → docs. Pick them out of sequence, and git won't know how to apply them.
Cross-branch dependencies! You need exactly 5 fixes across 3 branches. Pick them in strict order: INIT → DB → API → LOGIC → UI.
Flip between the three outcomes to see how your hotfix branch's history would look, depending on whether you cherry-picked, merged, or rebased the feature branch.
You picked precise commits, resolved order conflicts, pulled off a three-tree backport, untangled a web of dependencies, and compared the resulting history against merges and rebases. That's everything git cherry-pick is for.