Can we communally deprecate git checkout?

Original Article ↗ Hacker News Discussion ↗

Git’s long‑standing `checkout` command is being questioned as needlessly overloaded, since it both switches branches and rewrites files in the working tree, sometimes with surprising or destructive effects. Many engineers argue newer commands like `git switch` and `git restore` better separate these concerns and should be taught to newcomers, while others defend `checkout` as simple enough if you understand Git’s underlying model and worry about retraining costs and documentation warnings that label the new commands “experimental.” The exchange broadens into whether Git is inherently too complex, how much users should be expected to learn its internals, and whether GUIs or workflow conventions are a better way to make version control safer and more approachable.

git checkout vs switch / restore

  • Many agree checkout conflates distinct actions: switching branches, updating files, and sometimes moving HEAD.
  • Supporters of switch/restore say they reduce cognitive load by separating “change branch” from “change files,” and are safer for beginners.
  • Critics argue checkout conceptually “just updates the working tree” and is fine; switch/restore feel like minor syntactic sugar not worth relearning.
  • A major complaint: checkout infers whether an argument is a ref or a path, which can be ambiguous. The -b flag (create branch + switch) is seen as another conflation.

Complexity, mental models, and UX

  • One camp insists Git is fundamentally simple for competent engineers; complexity complaints are overblown and often workflow issues.
  • Another camp says Git’s interface and docs are messy, its concepts leak through everywhere, and it punishes users who don’t understand its internal model.
  • Some suggest Git is fine as “plumbing,” but its “porcelain” and UX are poor; a good tool should let you operate correctly without understanding Merkle trees.

Merge vs rebase

  • Several explanations contrast merge (history-preserving, branchy, faster in the moment) vs rebase (linear history, rewritten commits, easier debugging for some).
  • Some see rebase as risky and time-wasting; others say it’s easy to recover via rebase --abort, tags, or reflog.
  • A common pattern: rebase locally for cleanliness, merge once changes are shared.

Safety, data loss, and footguns

  • Checkout is noted as one of the few commands that can irreversibly destroy data without --force.
  • Others argue reset is the real “hot mess” and more dangerous than checkout, making the suggestion to “teach reset instead” alarming.

Tooling, GUIs, and non-engineers

  • Some say non-engineers shouldn’t touch Git at all; if they must, that’s an organizational problem.
  • Others counter that in labs, startups, and multidisciplinary teams, non-engineers inevitably use Git, often via GUIs, so simpler commands and better UX matter.

Habits, aliases, and teaching

  • Several people stick with checkout (checkout -b especially) due to muscle memory; others deliberately retrained to use switch/restore, sometimes via shell traps.
  • There is broad agreement that teaching new users clearer commands and workflows is valuable, but no consensus that checkout should be “communally deprecated.”