The merge vs. rebase debate

Original Article ↗ Hacker News Discussion ↗

Git users remain split over whether merge commits, rebasing, or squash‑merging produce the most useful project history. Proponents of rebasing and squash workflows value a linear, “curated” main branch that simplifies `git bisect`, reverts, and reasoning about changes, especially at scale or in trunk‑based development. Critics counter that rewriting history is fragile, obscures what actually happened, and can be too error‑prone for less experienced teams, arguing instead for merge‑based or patch‑based workflows where messy but accurate histories are preserved and tooling—not developers—absorbs the complexity.

Merge vs. Rebase (and Bisectability)

  • Many argue rebase-managed, linear histories make git bisect and reasoning about changes far easier; merge-heavy histories are described as “hairballs” that often reduce bisect to “somewhere in this big merge.”
  • Others counter that git log --first-parent and bisect options mitigate merge complexity, and that well-structured merge commits can be as understandable as squashed ones.
  • Some stress that large, conflict-heavy rebases are painful and error-prone, especially on active, multi-contributor repos.

Squash Merges and Commit Granularity

  • Pro‑squash: main/trunk should contain atomic, revertable units (PRs or change-sets), not “wip/fix typo” noise; squashing is seen as the simplest way to keep history clean where commit hygiene is poor.
  • Anti‑squash: squashing can bury important logical steps (e.g., helper introduction, mechanical refactors, tricky edge-case change) into a single giant diff, complicating blame, review, and future understanding.
  • Several adopt a mixed strategy: squash noisy PRs, preserve thoughtfully structured commits via rebase+ff merges.

Workflows and Branching Models

  • Example workflows:
    • Squash feature branches into staging, then merge staging → master for releases.
    • Trunk-based or very short-lived branches with frequent deploys vs 2–3 week feature branches.
  • Some teams value consistent, simple rules (e.g., “always squash”) to reduce cognitive overhead; others prefer “it depends,” choosing per-PR.

Tooling and Alternatives

  • Tools like Sapling and git-absorb are praised for making stacked diffs and commit cleanup easier (e.g., auto-amending edits back into the right commit).
  • Some see Git’s model (branches as pointers, awkward merge history) as a fundamental limitation; alternatives like Mercurial or patch-based/stacked workflows are mentioned as conceptually cleaner.

Philosophy: “Accurate” vs “Curated” History

  • One camp wants history to reflect what actually happened, including false starts and messy commits, arguing that rewriting history is “lying” and can hinder audits or debugging.
  • The other camp sees history as a curated narrative of logical changes, not an immutable lab notebook; they prioritize readability, smaller logical steps, and easier archeology over recording every misstep.
  • Both sides agree that commit discipline and a shared “git style guide” matter more than any single rule.