I kind of like rebasing

Original Article ↗ Hacker News Discussion ↗

Overall sentiment

  • Many commenters say they “like” or heavily rely on rebasing; a substantial minority prefer merge-only or don’t care enough to learn rebase deeply.
  • Most agree: rebasing is fine on private branches, risky on shared/public branches unless everyone is aligned.

Perceived advantages of rebasing

  • Lets people commit early/often in a messy way, then reshape history into clean, atomic commits before publication.
  • Produces linear history that’s easier to read with git log, git log -p, and tools like bisect.
  • Makes it easier to split work into logically separate changes, move preparatory refactors out of big features, and present a narrative of the change.
  • Some find merge commits conceptually harder (multiple parents) than a rebased linear chain.

Critiques and risks of rebasing

  • Rewriting history can confuse collaborators, especially if they’ve based work or reviews on older commits.
  • Force-pushing after rebase is seen as a footgun; people recommend --force-with-lease and protected branches, but cognitive load remains.
  • Rebase can create “fake” intermediate commits that were never tested or even built, harming bisectability.
  • Some argue preserving the messy “true history” has value for forensic debugging and understanding how things actually evolved.

Merge, squash, and history strategies

  • Popular compromise: do whatever you want on feature branches, then squash-merge or rebase-and-merge into main for linear main history.
  • Others strongly oppose squash-merge-to-one-commit because it discards carefully curated atomic commits and harms bisect and blame.
  • Merge-centric workflows are praised for resolving conflicts once per branch, preserving real intermediate states, and avoiding commit-identity churn.

Atomic commits, debugging, and bisecting

  • Many value small, self-contained commits with good messages for debugging, blame, and understanding complex changes.
  • Some see little real-world use of history beyond linking to tickets/PRs and feel heavy history grooming isn’t worth the time.

Tooling and UX

  • Several note that raw git rebase -i UX is rough; GUIs (Magit, Fork, JetBrains, others) or tools like git-revise make complex rebases safer and more ergonomic.
  • Features like rerere, --update-refs, --exec in rebase, worktrees, and git log --first-parent are frequently mentioned as workflow aids.