Suggest an edit

Improve this article

Refine the answer for “What is git cherry-pick and when to use it?”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

**`git cherry-pick`** copies a specific commit from one branch and applies it to your current branch as a new commit.

## Theory

### TL;DR

- Cherry-pick is like picking one cherry off a branch without shaking the whole tree: you get exactly that one commit, nothing else.
- It creates a **new commit** with the same changes, same message, and same author, but a fresh hash and your branch as the parent.
- Main difference from merge: merge pulls in the entire branch history; cherry-pick takes just one commit's diff.
- Decision rule: 1-3 commits you need selectively? Use cherry-pick. More than 5? Use merge or rebase.

### Quick example

```bash
# main has a bugfix, develop is missing it
git log --oneline main
# a1b2c3d Fix login crash  <- want this
# f4e5d6c Initial commit

git checkout develop
git cherry-pick a1b2c3d

git log --oneline develop
# b7c8d9e Fix login crash   <- new hash, same changes
# f4e5d6c Initial commit
```

The new commit on `develop` has the same message and diff but a different hash. The original stays on `main` untouched.

### How cherry-pick works

Git extracts the diff from the target commit (the exact patch of changes) and applies it to your working directory using a three-way merge. If it applies cleanly, Git commits automatically, preserving the original author, date, and message. If there are conflicts, it pauses and lets you resolve them. That three-way merge is why cherry-pick handles moved lines better than a plain `git apply`.

### When to use

- **Security hotfix to a release branch**: the patch landed on `main`, production is on `release/v4.17`, and you need that one commit there now.
- **Backport a specific bugfix**: a stable branch gets one fix from `main` without pulling unfinished features along with it.
- **Extract one commit from a feature branch**: the rest of the feature isn't ready, but one commit is safe to ship.
- **Avoid it when**: you need 5+ commits. Cherry-picking many commits creates duplicate history and makes future merges painful. Use `git merge` or `git rebase` instead.

### Common mistakes

**Mistake 1: Cherry-picking a merge commit without `-m`**

```bash
git cherry-pick M
# fatal: commit M is a merge but no -m option given
```

A merge commit has two parents. Git doesn't know which side to diff against. Fix:

```bash
git cherry-pick -m 1 M  # -m 1 = use the first (mainline) parent
```

**Mistake 2: Using `git commit` after a conflict instead of `--continue`**

```bash
# You resolved the conflict, then:
git add .
git commit -m "Fixed"  # Wrong - loses cherry-pick metadata

# Correct:
git add .
git cherry-pick --continue
```

**Mistake 3: Wrong range syntax**

```bash
git cherry-pick A..C   # Applies B and C, skips A
git cherry-pick A^..C  # Applies A, B, and C - usually what you want
```

The `A..C` notation excludes `A`. Add `^` to include it.

**Mistake 4: Short hash collision on large repos**

In repos with long histories (think Linux kernel), short hashes can collide. Verify before you pick:

```bash
git log --oneline | grep a1b2c3
git cherry-pick a1b2c3d4e5f6  # use the full hash when unsure
```

### Real-world usage

- **Kubernetes**: cherry-picks CVE security patches from `main` to `release-1.28` without pulling unrelated changes.
- **Node.js**: applies crypto vulnerability fixes to `v18.x` stable from `main` (e.g., the v18.17.1 release).
- **React**: ports isolated performance fixes from `canary` to `stable/18` for specific edge cases.
- **Linux kernel**: backports driver fixes to stable branches using commit ranges.

### Follow-up questions

**Q:** What is the difference between `git cherry-pick` and `git revert`?
**A:** Cherry-pick applies a commit forward, adding its changes to your branch. Revert creates a new commit that undoes a previous commit's changes. Revert is safer on shared branches because it never rewrites history.

**Q:** How do you cherry-pick a range of commits including the start?
**A:** `git cherry-pick A^..B`. The `A..B` syntax excludes `A`, so you add `^` to include it.

**Q:** What happens to the original commit's author and date?
**A:** Both are preserved in the new commit. The committer and committer date reflect you and the current time.

**Q:** When does cherry-pick succeed where `git apply` would fail?
**A:** Cherry-pick uses three-way merge, so it handles cases where surrounding code has shifted or moved. `git apply` is a dumb patch and fails whenever context lines don't match exactly.

**Q:** In a monorepo with strict dependency tracking, why might teams prefer cherry-pick over merge for hotfixes?
**A:** Merge brings the full branch graph, which adds noise to the dependency history and can confuse automated scanners. Cherry-pick copies only the diff, keeping the commit graph linear and the change traceable to a single point.

## Examples

### Basic: Hotfix to a release branch

```bash
# Security fix landed on main
git checkout main
git log --oneline -3
# a1b2c3d Fix: validate req.body size (prevents DoS)
# ...

# Apply to the production release branch
git checkout release/v4.17
git cherry-pick a1b2c3d

# Verify
git log --oneline -2
# f9e8d7c Fix: validate req.body size (prevents DoS)
# 3a2b1c0 Previous release commit
```

One command, one commit. The release branch gets the fix without absorbing everything else from `main`. This is the most common cherry-pick scenario in production codebases.

### Intermediate: Handling a conflict during cherry-pick

```bash
git checkout feature-stable
git cherry-pick b2c3d4e
# CONFLICT (content): Merge conflict in src/auth.js

# Open src/auth.js, resolve the conflict markers
# Then:
git add src/auth.js
git cherry-pick --continue
# [feature-stable e5f6g7h] Add token expiry check
```

If you change your mind mid-way, `git cherry-pick --abort` restores the branch to exactly the state before you started. I've reached for `--abort` more than once when a conflict made it clear the commit depended on other changes that weren't in the target branch yet.

Markdown · drag & drop images · ⌘B / ⌘I shortcuts966 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.