Cherry-picking in Git means taking one specific commit’s changes from a branch and replaying those changes onto another branch, without merging the whole branch history.

Quick Scoop: What is cherry-picking in Git?

In Git, cherry-pick lets you say: “I want that commit, but not the rest of the branch.” Instead of merging or rebasing an entire line of work, Git takes the diff (the changes) from a given commit and applies those changes to your current branch, creating a new commit with a new hash.

A simple mental picture:

You have a feature branch with 5 commits, but production only needs the small bugfix in commit #3.
With git cherry-pick <hash-of-commit-3>, you bring just that bugfix onto main, leaving the rest behind.

Why and when people use cherry-pick

Common real-world uses today:

  • Hotfixes for production
    You fix a critical bug on a feature branch but can’t merge the whole feature yet; you cherry-pick just the fix onto main or a release branch.
  • Moving a commit that landed on the wrong branch
    If you accidentally commit to the wrong branch, you can cherry-pick that commit onto the correct one and then reset or clean up the mistake.
  • Reusing a small change across multiple branches
    The same tweak (e.g., logging change, small refactor) is needed in several release branches; you cherry-pick the commit into each branch instead of re‑implementing it.
  • Saving work from an abandoned branch
    If you decide to drop a branch but want to keep a few good commits from it, you can cherry-pick those onto a maintained branch before deleting the old one.

How cherry-pick actually works (under the hood)

Git cherry-pick does not copy a whole snapshot; it applies the patch represented by the chosen commit.

Behind the scenes, roughly:

  1. Git locates the commit you specify (by hash or reference).
  1. It computes the diff between that commit and its parent (what changed in that commit).
  1. It applies that diff to your current working tree.
  1. You then get a new commit, on your current branch, with the same changes but a different parent and a new hash.

If the code has diverged too much between branches, you may get conflicts, and you must resolve them just like a merge conflict before finishing the cherry- pick.

Cherry-pick vs merge vs rebase (why it’s different)

Here’s a compact comparison:

Action What it does History effect Best used when...
Cherry-pick Apply specific commits (their diffs) from one branch onto another. Creates new commits with new hashes, duplicates changes without bringing full history. You need one or a few targeted commits (e.g., a hotfix) without merging the whole branch.
Merge Combine the full history of one branch into another as a whole. Preserves all original commits and creates a merge commit (unless fast‑forward). A feature branch is ready and you want everything it contains integrated.
Rebase Replay commits from one branch on top of another base. Rewrites history, creating new commits with new parents and hashes. You want a cleaner, more linear history before merging or sharing.
[8][3][7]

Basic commands (short practical view)

Basic usage pattern:

  • Start from the branch you want to apply the change to:
    • git switch main (or git checkout main)
  • Run cherry-pick with the commit hash:
    • git cherry-pick <commit-hash>

If you encounter conflicts, you generally:

  1. Fix conflicts in the affected files.
  2. Stage fixes: git add <file>
  3. Continue: git cherry-pick --continue
  4. Or abort if needed: git cherry-pick --abort

Pros, cons, and current “forum” vibe

In docs, blogs, and Q&A forums, people often describe cherry-pick as very powerful but easy to misuse.

Pros people like:

  • Very targeted: brings in just what you want, nothing else.
  • Great for hotfixes and backports across long-lived branches.

Common cautions:

  • It can duplicate commits across branches, which can confuse history if overused.
  • Repeated cherry-picks of related commits can get messy, especially if the code keeps changing and conflicts grow.

A typical “modern” guideline you’ll see is:

Use cherry-pick for surgical changes (hotfixes, backports, rescuing a few commits); prefer merge or rebase for regular feature integration.

Tiny example story

Imagine:

  • You have feature/login-enhancements with commits:
    • A – add login form
    • B – refine UI
    • C – critical security fix

The branch isn’t ready to merge because A and B are still under review, but production urgently needs the security fix in C. You switch to main and run:

  • git cherry-pick <hash-of-C>

Now main has the security fix as a fresh commit, even though the rest of the feature work stays only on the feature branch.

TL;DR:
Cherry-picking in Git is selecting one or more specific commits from somewhere in your repo and replaying just those changes onto another branch, usually for targeted fixes or backports, without merging the entire branch history.

Information gathered from public forums or data available on the internet and portrayed here.