Cherry-Picking

Sometimes you need exactly one commit from a branch and absolutely nothing else. git cherry-pick copies that single commit anywhere you want it, and it is the fastest way to get a hotfix onto a test environment.

Why This Module Matters

Picture a release branch frozen for regression testing. A developer fixes a crash on develop, in a branch that also contains three unfinished features. You need the crash fix on the frozen branch tonight; the features must not come with it.

Merging is the wrong tool — it brings everything. Copying the diff by hand loses the authorship and the message. Cherry-pick is the right tool: it takes the change introduced by one commit and applies it as a new commit wherever you are standing.

For QA this is a routine motion. Backporting a fix to a release branch, putting one candidate patch on a staging environment to confirm a bug is really gone, reconstructing a minimal reproduction from a commit buried in a long branch — all cherry-pick.

It also has a sharp edge worth respecting: the copy is a different commit with a different ID, so if the original branch is merged later, the same change can appear twice.

What You'll Learn

• What cherry-pick copies, and why the new commit gets a new ID
• Applying a single commit onto a release or test branch
• Picking a range of commits, and -n for staging without committing
• -x, which records the original commit ID in the message — invaluable for traceability
• Handling a conflict during a pick: --continue, --abort, --quit
• The duplicate-commit trap, and how git cherry and git log --left-right reveal it

Pro Tip

Always cherry-pick with -x when moving a fix between long-lived branches. Six weeks later, "cherry picked from commit 8f3c2a1" in the message is the only thing that will tell you where the change really came from.