In Git, what does git cherry-pick do to the commit you name?
answer
- it copies a change, it does not move it
- the source branch is untouched
- the result is a brand new object
- parent and committer differ from the original
- think targeted backport, not merge
basics
~20 sIt applies that commit's change on top of your current branch and creates a new commit for it. The original commit stays where it is; the copy has a different SHA because its parent, committer and timestamp differ.
solid answer
~40 s`git cherry-pick <commit>` takes the **diff** that commit introduced relative to its parent, applies it to your current `HEAD`, and commits the result — reusing the original message and author, but recording you as committer with a new timestamp and a new parent. That gives a **new commit with a different SHA**; nothing moves, and the source branch is untouched. It can conflict like any other application of a patch, and then you resolve, `git add`, and run `git cherry-pick --continue` (or `--abort` / `--skip`). You can pick several commits at once by listing them or by giving a range such as `A..B`, which picks everything after `A` up to `B`. The typical use is a targeted backport: one bug fix from the main branch onto a release branch, without dragging along everything else.
code
console · 5 lines$ git switch release-1.4
$ git cherry-pick 9f2a1c3
[release-1.4 7c31af0] fix null deref in session lookup
Date: Mon Aug 10 09:12:44 2026 +0200
1 file changed, 3 insertions(+), 1 deletion(-)go deeper
Be able to say cherry-pick copies one commit's change onto your current branch as a new commit, and that the original branch is unchanged.
Explain which metadata carries over and which does not, why the SHA changes, and how ranges, -n and the conflict flow work.
Show judgment about backports: when a fix should be picked versus merged, what a conflicting pick tells you about divergence, and how duplicates play out later.
Own the maintenance-branch policy — what is eligible for backport, who decides, and how the team avoids a web of hand-copied fixes across release lines.
## What it does A commit records a full snapshot, but Git can compute the **change** it introduced by diffing it against its parent. `git cherry-pick <commit>` computes that change and applies it to your current branch, then commits. The copy is a genuinely new commit object. It keeps the original **author** and author date and reuses the message, but its parent is your current `HEAD`, its committer is you, and its committer date is now. Since a commit's SHA hashes all of that, the SHA is different. Two commits with the same message and the same diff sitting on different branches is exactly what a cherry-pick looks like in the log. The source branch is not modified at all — nothing is moved or deleted. Cherry-pick copies. ## Everyday form git switch release-1.4 git cherry-pick 9f2a1c3 Useful variations: - **Several commits**: `git cherry-pick A B C` applies them in the order given. - **A range**: `git cherry-pick A..B` applies every commit after `A` through `B`. The left end is exclusive; `A^..B` includes `A`. - **`-n` / `--no-commit`**: apply the change to the working tree and index but do **not** commit, so you can adjust it or combine several picks into one commit. You commit yourself afterwards. - **`-e` / `--edit`**: open the message for editing. - **`-s` / `--signoff`**: add a `Signed-off-by` trailer. - **`-x`**: record the source commit id in the message of the copy. ## Conflicts A cherry-pick is an application of a change onto a different base, so it can conflict — especially when the surrounding code has diverged. Git stops with conflict markers in the tree, records `CHERRY_PICK_HEAD`, and waits. You resolve, `git add` the files, and run `git cherry-pick --continue`. `--abort` restores the branch to where it was; `--skip` drops the current commit and moves on to the next in a multi-commit pick; `--quit` leaves the tree as-is but clears the in-progress state. During a multi-commit pick the remaining plan lives in `.git/sequencer`. A conflict is also a signal worth reading: if a fix does not apply cleanly to a release branch, the code it fixes may have changed enough that the fix is not the right one there. ## When to reach for it - **Backporting** a bug fix from the main line to a maintenance or release branch. - **Rescuing** a commit made on the wrong branch: pick it onto the right branch, then remove it from the wrong one. - **Extracting** one useful commit from an abandoned branch. ## When not to Cherry-pick is a scalpel. Picking dozens of commits one at a time is a sign you actually wanted to merge or rebase the branch: those tools track what has already been integrated, while repeated cherry-picks leave you managing duplicates by hand. The long-term consequence of copying is **duplicate commits**: the same change exists twice, with two SHAs. If the source branch is later merged into the target, Git's three-way merge usually copes because both sides made the same textual change, but the history now contains two commits for one logical fix, and a partially cherry-picked branch can produce confusing conflicts. Git does have tooling for spotting such duplicates by comparing patch identity rather than SHA. ## Common misconceptions - "It moves the commit" — no, the original stays put. - "The SHA is the same" — it cannot be, because the parent changed. - "It brings the whole branch" — it brings exactly the changes of the commits you name. - "A merge commit can be picked like any other" — a merge has two parents, so Git cannot tell which diff you mean unless you say, with `-m`.
- Why does the cherry-picked commit have a different SHA from the original?A commit's SHA hashes its tree, message, author and committer identity and timestamps, and its parent. The copy has a different parent — your branch tip — and a fresh committer line, so the hash differs even when the diff and message are identical. Cherry-pick copies changes; it never relocates a commit object.
- What does git cherry-pick -n do, and when is it useful?`-n` (`--no-commit`) applies the change to the working tree and index but stops short of committing. It lets you adjust the change before recording it, or apply several picks and commit them once as a single logical change. You commit yourself afterwards, which also means you write the message.
- How do you cherry-pick a range of commits rather than one?Give a range: `git cherry-pick A..B` applies every commit after `A` up to and including `B`, in order. Use `A^..B` when you want `A` itself included. Each one becomes its own new commit, and a conflict pauses the sequence so you can resolve, then `--continue`, `--skip` or `--abort`.
It is photocopying one page from one binder into another: the original page stays in place, and the copy is a distinct sheet with its own page number.
saying these in an interview costs you the question
- Saying cherry-pick moves the commit off the source branch
- Claiming the copied commit keeps the original SHA
- Thinking cherry-pick brings the whole branch's history
- Assuming a cherry-pick can never conflict
- Reaching for dozens of picks where a merge or rebase was meant