How Git cherry-pick and revert use 3-way merge

Original Article ↗ Hacker News Discussion ↗

Git’s cherry-pick and revert commands are revealed to use full 3-way merges under the hood, which explains why they often behave more robustly than simple patch application. From there, developers debate broader Git workflows and mental models — especially merge vs. rebase, squash merges, and trunk-based development — and how these choices affect history clarity, conflict frequency, and team productivity. Many argue that Git’s power justifies its complexity, but emphasize good tooling, tutorials, and understanding Git’s underlying graph structure as key to avoiding painful errors.

Overall reaction to the article

  • Many found the explanation of cherry-pick/revert using 3‑way merge clarifying; it confirmed intuitions that these operations are “smarter than a flat patch.”
  • Some were surprised cherry-pick is implemented as a 3‑way merge and that rebase is essentially a sequence of cherry-picks.
  • A few noted minor nits, e.g., linking to master branch instead of specific commit hashes for long‑term stability.

Git complexity, mental models, and UX

  • Multiple comments complain Git feels overly complex, especially when fixing history or resolving others’ mistakes.
  • Others argue the power/complexity is necessary for large, distributed teams and that problems often stem from weak mental models.
  • Several stress understanding Git’s underlying graph/snapshot model (commits as full trees, not patches) rather than memorizing commands.
  • Good visual UIs and tutorials (graph views, conflict tools, sites like learngitbranching and “plumber’s guide” style docs) are seen as very helpful.

Merge vs rebase vs squash: competing philosophies

  • Strong split between “always merge” and “rebase for linear history” camps.
  • Merge advocates:
    • Prefer explicit merge commits, no (or rare) rebases, and often squash feature branches to one commit.
    • Argue merges are conceptually simpler, conflicts are easier, and rebasing shared branches is dangerous.
  • Rebase advocates:
    • Rebase local/topic branches frequently to keep history linear and bisectable; use interactive rebase to craft clean, atomic commits.
    • See squash merges as hiding messy development and reducing the value of history.
  • Some note practical trade‑offs: long‑lived branches make rebases painful (repeated conflicts), while messy feature-branch histories make unsquashed merges noisy.

Workflows and team practices

  • Trunk-based development with short-lived branches and feature flags is praised, especially for SaaS.
  • Others use very minimal command subsets and avoid advanced features to stay out of trouble.
  • There’s disagreement over how much structure small teams really need versus process being overcomplicated for “safety.”

Technical notes on 3-way merge and conflicts

  • Several highlight merge.conflictStyle=diff3 / zdiff3 and visual 3‑way tools as major aids in resolving conflicts.
  • Discussion clarifies that 3‑way merge predates Git and is non‑associative, which can yield surprising behaviors; some speculate about richer merge schemes (e.g., “four-way” contexts).
  • Cherry-pick and rebase are framed as ways of applying diffs using 3‑way merge, which can succeed where naïve git apply-style patches would fail.