Git cheat sheet [pdf]

Original Article ↗ Hacker News Discussion ↗

A new Git cheat sheet prompts renewed scrutiny of why Git feels so hard to learn, with many arguing that its underlying data model is elegant but its command-line interface and naming are unnecessarily confusing. Commenters trade tips and lesser-known commands, emphasize learning core concepts or using GUIs and tools like Magit, Sourcetree, or IDE integrations to tame complexity, and debate how much of Git’s power most developers actually need. Several point to alternatives such as Mercurial, Fossil, and especially Jujutsu (jj) as attempts to preserve Git’s strengths while offering a more coherent, workflow-oriented user experience.

Git’s complexity and origins

  • Debate over whether Git is “needlessly” complex or just matching a complex problem domain (Linux kernel–scale, decentralized development).
  • Some argue it was built quickly for one project with no UX focus, so design is “one person’s best idea” rather than ideal.
  • Others note that earlier internal constraints (e.g., cost of adding subcommands) led to overloaded commands like checkout, worsening UX.
  • History with BitKeeper and Subversion is mentioned; Git seen as better for branching/merging and massive repos, but not necessarily ideal for all projects.

UI vs underlying model

  • Strong consensus that the core model (commits, trees, blobs, refs) is simple and powerful, but the CLI is confusing and inconsistent.
  • Complaints about many ways to do the same thing, evolving commands (reset/checkout vs switch/restore), and hard-to-memorize flags.
  • Some defend Git’s interface as manageable once terminology and concepts are learned.

Alternatives and frontends

  • Jujutsu (jj) repeatedly recommended as a Git-compatible tool with a simpler mental model and friendlier workflows, especially for history editing and conflict handling.
  • Mercurial praised for UI but criticized for performance on huge codebases; Fossil and Subversion suggested for simpler or solo workflows.
  • Many recommend GUIs and TUI tools (Magit, Fork, GitKraken, Sourcetree, SmartGit, IntelliJ’s Git UI, lazygit, Sublime Merge) to avoid raw CLI complexity.

Learning curve and “curse of knowledge”

  • Several note that even experienced developers struggle beyond basic commands; many only know a small subset (clone/pull/add/commit/push).
  • Some argue a VCS shouldn’t take years to feel safe; others say deep understanding requires deliberate study and practice.
  • The “curse of knowledge” is invoked: experts underestimate how opaque Git feels to newcomers.

Tips, tricks, and minor debates

  • Popular commands/features highlighted: add -p, diff --staged/--cached, commit --fixup + rebase --autosquash, cherry, log -L, log -S/-G, commit -v, reflog usage.
  • Some prefer manual patches or simple workflows over stash/branches.
  • Naming like git blame is criticized as negative; alternative names like “praise” are suggested.
  • Cheat sheet generally praised, with requests for tags and some nitpicks on notation, fonts, and minor inaccuracies.