Cherry-pick
A one-line fix lands on main as commit a1b2c3d, but the same bug is still live on release/v2.5. Merging the whole branch drags along ten unrelated commits; you want that single change and nothing else.
- ▸The same one-line fix can live in two commits at once, each with its own hash.
- ▸A merge commit has two possible changes; ask git to copy one without saying which parent, and it refuses.
- ▸Copy five commits, hit a conflict on the third: two are done, three wait on disk, one command rewinds all.
Commit e67b797, "Fix null check in config loader", sits on your hotfix branch. The same bug is live on main, and it needs the same one-line change. You do not want the other three commits on hotfix, just this one.
Name that commit by its hash, and git takes the change it introduced, the diff against its own parent, and applies that change on top of whatever branch you are standing on. It records the result as a brand-new commit on main. The original commit on hotfix is never touched: its bytes still sit in .git/objects/, still reachable from hotfix, exactly where they were.
So the change now exists in two places at once. Not moved, not relocated, copied. One diff, two commits, on two branches. The viz gives you a second branch and a commit to lift across: place the copy and watch the original stay put.