Git rebase -i is not that scary

Original Article ↗ Hacker News Discussion ↗

Interactive `git rebase -i` is portrayed as a powerful but underused tool for reshaping commit history, with many developers arguing that basic fluency in it—and in Git’s underlying data model—is essential for serious software work. Commenters share concrete workflows (fixup/autosquash, `git add -p`, using reflog, tags and throwaway branches) to make rebasing safer and less intimidating, and point to editor integrations and newer tools like `jj` and `git history` that further streamline the process. Others push back on “rebase purity,” questioning how much meticulously curated history really helps compared to simpler merge workflows, especially given Git’s confusing UI and the risk of conflicts.

Overall sentiment on git rebase -i

  • Many commenters see interactive rebase as a core, non‑scary skill that gives precise control over history, improves reviews, and should be part of every developer’s toolkit.
  • Others find it overhyped, tedious, or unnecessary for simple workflows, criticizing Git’s confusing CLI and the “rebase cult” around immaculate histories.

Learning curve, understanding Git, and culture

  • Strong camp: if you’re scared of rebase you don’t really understand Git’s data model; investing a few hours pays off over a career. Some even treat fear of rebase as an interview red flag.
  • Opposing camp: Git’s UX is objectively bad; many teams only need a small subset, and focusing heavily on rebase in interviews is a red flag itself.
  • Some frame mastery of shell, editor, and VCS (including rebase) as the three essential “afternoons” of learning.

Safety, recovery, and backups

  • Emphasis that committed data is hard to truly lose; reflog, ORIG_HEAD, and magic refs allow undoing botched rebases.
  • Others note that this assumes knowing reflog and being able to interpret it; they recommend low‑tech safeguards: temporary branches, tags as savepoints, or even copying .git.
  • Several highlight that hosts like GitHub rarely garbage‑collect, so pushed commits may effectively live forever, which is both safety net and security risk.

Conflict handling strategies

  • Common fears center on subtle mistakes during conflict resolution, not rebase itself.
  • Mitigations: merge.conflictStyle=zdiff3/diff3, git rerere, range-diff, and comparing pre/post‑rebase heads.
  • Tactics include: aborting large, messy rebases; squashing first; doing reordering and then a separate autosquash pass; or restarting branches when conflicts get too complex.

Workflows, tools, and aliases

  • Heavy use of --fixup/--squash with --autosquash; edit for splitting or amending old commits; git add -p/partial staging.
  • Some prefer GUIs/TUIs (GitLens, magit, git gui) for interactive rebase or hunk staging.
  • Several share aliases and configs to streamline amend/fixup workflows; one warns against teaching short flags to beginners.

Alternatives and automation

  • Alternatives like jj, Fossil, Mercurial, and Git’s evolving commands (switch, restore, history, maintenance) are mentioned as attempts to improve UX.
  • A few say they now largely outsource rebases/commits to agents or LLMs, with warnings to commit or stash first.