Resistance Against Git Merge Hell (2015)
Heavy use of Git merge commits can turn project history into an unreadable “tube map,” prompting debate over how much teams should favor rebasing, squashing, or merging to keep history understandable. Commenters weigh trade-offs between preserving every intermediate step for tools like `git bisect` and `git blame` versus curating a linear, review-friendly history, with many advocating: messy personal branches, cleaned up via interactive rebase before sharing, and immutable public branches where history is never rewritten. Others argue the real solution lies in better tooling and log queries (e.g., `--first-parent`, filtering merges) rather than enforcing a single “clean” workflow.
Overall tension: clean vs “true” history
- Some see “clean history” as subjective marketing; all info is in the graph and tools like grep/bisect exist, so visual mess isn’t a crisis.
- Others argue dense merge graphs are practically unreadable and harm forensics, review, and blame.
- There’s broad agreement that commit history never fully reflects how code was written; it’s about making later reasoning easier, not preserving every step.
Merge vs rebase
- Pro‑rebase:
- Linear history is easier to understand, review, and bisect.
- Interactive rebase helps turn chaotic local work into clear, logical commits.
- Rewriting private branches is seen as good hygiene; “never rewrite history” is reserved for shared/public branches.
- Anti‑rebase / cautious views:
- Rebasing “invents” intermediate commits that never existed or were tested; squash is preferred to avoid fake states.
- Rebase conflicts can be more painful than merge conflicts, especially across many commits.
- Rewriting shared branches (e.g., default branch) is strongly discouraged due to disruption.
Squash merges and commit granularity
- One camp: always squash into main; nobody cares about the internal noise of feature branches and it keeps main bisectable and simple.
- Another camp: squashing full features throws away carefully curated, atomic commits that help future blame, bisect, and understanding.
- Some advocate a middle path:
- Squash trivial fixups and WIP.
- Preserve meaningful, buildable commits that tell a coherent story.
History viewing and tooling
- Several note that many complaints are about presentation, not storage:
git log --first-parentor--no-mergescan surface only the main sequence.- Visual history can be useful for understanding branch divergence, but many never use it.
- Some wish for better query languages, interactive UIs, and features like “hidden” original commits that survive beyond reflog/GC.
Workflow, roles, and environments
- Debate over whether contributors should handle rebasing to keep PRs trivially mergeable vs this being a maintainer duty.
- Views differ on production/staging branches; some see separate production branches and rebasing as useful, others argue deployments should reuse the exact staging artifacts instead of new builds.