Cherry-pick, Revert, Reset — git-basics

Not all history is smooth. Sometimes you need to transplant a single commit, undo a mistake, or roll back history. Git gives you three sharp tools for this: cherry-pick, revert, and reset. Each has its own philosophy and danger level. In this chapter, we’ll learn what they do, when to use them, and how they shape history differently.

Cherry-pick: Selective Copying

Cherry-pick lets you take a single commit from one branch and apply it onto another. It’s like saying, “I want that one, please.”

git checkout main
git cherry-pick a1b2c3d

This applies commit a1b2c3d on top of main as a new commit.

Visualization:

gitGraph
  commit id: "A"
  commit id: "B"
  branch feature
  checkout feature
  commit id: "Fix typo"
  checkout main
  cherry-pick id: "Fix typo"

Cherry-pick is useful when a bugfix made in one branch is also needed elsewhere without merging the whole branch.

Revert: Safe Undo

git revert creates a new commit that undoes changes from a specific commit. It doesn’t erase history—it adds history.

git revert a1b2c3d

Visualization:

gitGraph
  commit id: "Bug introduced"
  commit id: "Bugfix commit"
  commit id: "Revert bugfix (reverts previous commit)"

The original commit remains in history, but its effects are canceled out by the revert commit. This is safe for shared history.

Reset: Dangerous Time Travel

git reset moves the branch pointer to another commit, optionally changing working directory and staging area. This rewrites history.

git reset --hard a1b2c3d

This discards commits after a1b2c3d. Those commits are no longer visible unless recovered via reflog.

Types of reset:

--soft: moves HEAD, keeps changes staged.
--mixed (default): unstages changes.
--hard: discards everything.

Visualization:

flowchart TD
    A[Commit A] --> B[Commit B]
    B --> C[Commit C]

    C -->|git reset --soft B| Soft[HEAD -> B<br/>changes staged]
    C -->|git reset --mixed B| Mixed[HEAD -> B<br/>changes unstaged]
    C -->|git reset --hard B| Hard[HEAD -> B<br/>changes discarded]

Reset is powerful but dangerous—never use --hard on shared branches.

Comparing the Three

Cherry-pick: copy a commit. Safe, surgical.
Revert: undo with a new commit. Safe, public.
Reset: move pointer back. Dangerous, private.

Visualization of usage contexts:

flowchart TD
  CherryPick[Cherry-pick] -->|apply fix selectively| Branches[Across branches]
  Revert[Revert] -->|undo safely| Shared[Shared history]
  Reset[Reset] -->|rewrite| Local[Local/private branches]

Solo Workflow Example

You’re working locally and commit a broken experiment. To roll back cleanly:

git reset --hard HEAD~1

No one else saw it, so reset is safe.

Team Workflow Example

On a shared repo, someone introduced a bug. Instead of rewriting history, you revert:

git revert a1b2c3d
git push origin main

This keeps history intact and transparent.

Meanwhile, cherry-pick helps when a fix on a feature branch must be applied to a hotfix branch.

Think Different Mindset

Cherry-pick, revert, and reset aren’t just commands—they’re philosophies of handling mistakes. Cherry-pick is surgical precision. Revert is honesty: mistakes remain visible but corrected. Reset is rewriting your own drafts before publishing. Together they teach us when to edit, when to acknowledge, and when to erase.

Cherry-pick copies, revert cancels, reset rewrites. Each has its place: cherry-pick for selective reuse, revert for safe undo, reset for local cleanups. Knowing when to use which is the difference between a careful historian and a chaotic time traveler. In the next chapter, we’ll explore stashing and WIP strategies for juggling unfinished work.