Some changes exist on exactly one branch — a fix that applies equally to main and to a release line, one commit from a feature you do not want wholesale. git cherry-pick copies a single commit onto your current branch: same change, new commit, new hash, no history surgery.
The basic pick #
$ git switch release/v1.4
$ git cherry-pick f3e2d1c
[release/v1.4 a7b8c9d] fix: correct cache headers on media
1 file changed, 2 insertions(+), 2 deletions(-)Git applies the commit's diff on top of your branch and creates a new commit — same message, same author, new identity. The original branch is untouched.
The routine cases #
| Situation | Flow |
|---|---|
| Hotfix must reach main and the release line | Fix on main, cherry-pick to release |
| One commit of a feature is needed now | Pick it; the rest waits |
| A teammate's branch has the fix; merge is premature | Pick that commit only |
| Rebuilding a lost branch | Pick survivors one by one |
The hotfix flow is the canonical one — fix once on main, propagate deliberately:
$ git switch main
# ... fix, test, commit (f3e2d1c), push ...
$ git switch release/v1.4
$ git cherry-pick f3e2d1cConflicts and options #
A pick conflicts like any apply when the surrounding code differs between branches:
$ git cherry-pick f3e2d1c
CONFLICT ...
$ # ... edit, git add ...
$ git cherry-pick --continue
$ git cherry-pick --abort # return to the starting point| Option | Effect |
|---|---|
-n / --no-commit | Apply changes to the tree without committing |
-x | Append "(cherry picked from ...)" to the message |
--continue / --abort | Drive a conflicted pick |
-x is the traceability flag: the message records the origin commit, so future merges between the branches can recognise the change and skip duplicating it. -n is for picking several commits into one, or amending before committing — a rebase -i flavour of cherry-picking.
Finding the right commit to pick is log and bisect work. The Git series continues.