Kelly Mears

Squash Merge

Collapsing a branch's commits into one before merging, trading granularity for a clean main history.

Version Control & Delivery1 min read200 words15 out · 21 in
also calledSquashing

A squash merge collapses every commit on a branch into a single commit on the target branch. The main line gains one commit per change, and the branch's intermediate steps disappear from it.

The trade is explicit. History on the main branch becomes clean and uniform — one entry per unit of work, easy to scan, easy to revert. The intermediate commits, including their individual messages, are gone from that history.

Two consequences follow that people meet in practice rather than in theory.

The squashed commit's message becomes the permanent record. Whatever the change description says is what the repository will hold, which is what makes an unverified claim in it a durable false statement. See Provenance and Plausible Mechanism.

The branch's commits are no longer ancestors of the main line. Any work still based on them has a base that main does not contain, so a subsequent push recreates the deleted branch as an orphan and a merge does strange things. Recovering means cherry-picking the wanted commits onto a fresh branch cut from the current main.

Squash merging pairs naturally with Trunk-Based Development, where branches are short and their internal steps are working notes rather than history worth keeping.

See also11

Commit

A recorded snapshot of a project with a message explaining it.

Version Control & Delivery23 connections

Atomic Commit

A commit containing exactly one logical change, complete and independently sound.

Version Control & Delivery19 connections

Branching Model

The convention governing what branches exist, what they mean, and how work reaches production.

Version Control & Delivery18 connections

Pull Request

A proposal to merge a branch, carrying review, automated checks, and the discussion around it.

Version Control & Delivery25 connections

Code Review

A second person reading a change before it lands, and the practices that make it worth the time.

Version Control & Delivery38 connections

Version Control

A system recording the history of a project's files, enabling branching, merging, and recovery.

Version Control & Delivery26 connections

Feature Branch

A branch created to develop one change in isolation before merging it back, a workflow that keeps the main line stable but grows riskier the longer the branch lives, since its divergence from everyone else's work compounds.

Version Control & Delivery16 connections

Staging Area

The intermediate snapshot in Git between the working files and the next commit, which lets a developer choose exactly which changes go into each commit, down to individual lines.

Version Control & Delivery15 connections

Git Bisect

Finding the commit that introduced a bug by binary search through history, testing the midpoint between a known-good and a known-bad version until one commit remains.

Testing & Verification17 connections

Fast-Forward Merge

The two basic ways Git joins branches, by sliding a branch pointer forward or by recording a new commit with two parents, and how the choice shapes a project's history.

Version Control & Delivery14 connections

Git Blame

Showing, for every line of a file, the commit and author that last changed it, the starting point for finding out why code is the way it is.

Version Control & Delivery12 connections

Linked from21