I kind of like rebasing

Original Article ↗ Hacker News Discussion ↗

Whether to rebase or merge in Git splits developers between those who prize a clean, linear history and those who value preserving every intermediate commit. Commenters weigh the benefits of interactive rebasing, squash merges, and atomic commits against risks like rewriting shared history, confusing collaborators, and degrading tools like `git bisect` when intermediate commits are broken. Many conclude that rebasing is powerful and safe on private branches when used with discipline, while teams should agree on clear rules (often squash-merging to main and avoiding rebases on shared branches) to keep collaboration and debugging manageable.

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.