glossaryThe git operation of combining multiple commits into a single commit, typically used to clean up work-in-progress history before merging a feature branch.
Squashing collapses a series of commits into one, replacing their individual messages with a single combined message. It is performed via git rebase -i (interactive rebase) by marking commits as "squash" or "fixup", or automatically during a pull request merge with the "Squash and merge" option in GitHub and GitLab. Squashing is often used to clean up noisy WIP history (commits like "fix typo", "try again", "actually fix it") before the commits become part of the permanent main branch history. The resulting single commit is easier to revert if the feature needs to be removed. The tension between squashing and atomic commits is important to understand. Squashing multiple atomic commits into one loses the granularity that makes atomic commits valuable for bisecting and blame. A balanced approach is to maintain atomic commits during development and review, then squash only WIP noise before merge — preserving logical units while eliminating checkpoint clutter.
# Before squash: 5 WIP commits on feature branchwip: start login flowfix: forgot to import componentfix: handle edge case# After squash merge: one clean commit on mainfeat(auth): add OAuth2 login flow with PKCEgit-agent creates clean, atomic commits from the start, reducing the need to squash. When you use git-agent commit, each logical change is already committed separately with a meaningful message, so the history is ready for review and merge without cleanup.
brew install gitagenthq/tap/git-agentShould I squash commits before merging a pull request?Does squashing break git bisect?Is 'Squash and merge' in GitHub the same as git rebase squash?