Theory

Updated

October 30, 2026

Theory: Cherry-Pick and Revert are Patches with New Hashes

Both operations take a diff (commit vs its parent, or the inverse) and apply it to HEAD, writing a new commit. They do not move the original node.

Invariants

  1. Cherry-pick(C) ≈ apply diff(parent(C), C) onto HEAD.
  2. Revert(C) ≈ apply diff(C, parent(C)) onto HEAD (the inverse patch).
  3. The original commit remains reachable if any name still points at it.
  4. Revert of a merge needs -m to choose which parent is the mainline; Git then considers those changes “already merged” for future merges.
  5. -x records cherry picked from in the message; it does not link objects.
 cherry-pick D onto main          revert C on main

 feat  A ← B ← C ← D ← E          A ← B ← C ← R
 main  A ← B ← C                  R undoes C; C stays
 after A ← B ← C ← D'

Why not reset on production

Reset moves a name backward. Clones that already have the old tip cannot fast-forward. Revert lets them fast-forward to a commit that cancels the bad one. That is the distributed-model consequence, not etiquette.

What can break

  • Cherry-picking a merge without -m.
  • Reverting a merge then trying to merge the same feature again (Git thinks it is in).
  • Secrets: revert does not purge blobs from history.

How to read this chapter

Cherry-pick, hotfixes, revert, emergencies; then ranges/-x, empty picks.