Squash merge
A squash merge collapses all commits on a feature branch into a single commit on main, discarding the intermediate history. The result is a clean main-line history where each commit corresponds to one merged PR, at the cost of losing the original commit-by-commit development trail.
Squash-merging is the de-facto default for GitHub-style PR workflows because it produces a readable main-line history. The trade-off: the original development commits (with their intermediate 'WIP', 'fix typo', 'address review comments' messages) disappear from main, so git-blame and git-bisect operate on the single squashed commit rather than the granular history. Teams that prefer full history use 'merge --no-ff' instead, which preserves every commit but produces a much noisier main-line graph. The choice is partly aesthetic and partly tooling-driven; most teams pick one and standardise across the org.
Related terms
- Pull request
A pull request (PR) — also called a merge request in GitLab / Bitbucket — is a proposal to merge changes from one git branch into another, typically with code review and CI checks gating the merge.
- Rebase vs merge
Rebase and merge are two strategies for integrating changes from one branch into another.
- Trunk-based development
Trunk-based development is a source-control workflow where engineers integrate small changes to a single shared branch (trunk / main) at least once per day, gated by automated tests and feature flags rather than long-lived branches.