How to squash commits

What It Is

Git commit squashing is a version control technique that combines multiple sequential commits into a single, unified commit. When you squash commits, all changes from the individual commits are preserved, but the commit history becomes cleaner and more logical. This technique is essential in professional development where commit history serves as documentation of intentional code changes. Squashing helps prevent cluttered commit logs filled with 'fix typo' or 'oops forgot this' commits.

The squashing technique emerged as Git usage matured in the early 2010s, with developers recognizing that verbose commit histories hindered code review and debugging. Git 1.7.0, released in February 2010, introduced improvements to interactive rebase that made squashing straightforward. By 2015, squashing became standard practice in open-source projects and enterprise environments worldwide. Today, most popular projects require squashed commits in pull requests, making this skill essential for modern developers.

There are several squashing approaches: interactive rebase (`git rebase -i`), soft reset (`git reset --soft`), and specialized commands in platforms like GitHub. Interactive rebase is the most common method, allowing precise control over which commits to squash and in what order. Soft reset works well for squashing all uncommitted changes into a single commit without rewriting history. Different workflows and team preferences determine which method is most appropriate for specific situations.

How It Works

The squashing mechanism operates through Git's rebase functionality, which replays commits on top of a different base commit. When you run `git rebase -i HEAD~3`, you tell Git to prepare the last three commits for modification. Git opens an editor showing each commit with an action keyword like 'pick', 'squash', or 'reword'. You change 'pick' to 'squash' (or 's') for commits you want to combine, and Git merges them during the rebase process.

In a practical example, imagine a developer named Sarah working on a feature branch who made three commits: 'Add login form', 'Fix validation bug', and 'Update styling'. She runs `git rebase -i HEAD~3`, changes the last two commits from 'pick' to 'squash', and Git combines all three into a single 'Add login form' commit. The resulting commit contains all changes from the three original commits but appears as one logical unit in the repository history. This keeps the main branch's history clean and focused on feature completion.

To implement squashing, create a feature branch, make multiple commits during development, then before merging run `git rebase -i HEAD~n` where n is your commit count. In the interactive editor, keep the first commit as 'pick' and change subsequent commits to 'squash'. Git will prompt you to edit the combined commit message, allowing you to write a single comprehensive message. Finally, force-push the rebased branch (if it's your personal branch) or create a pull request with the squashed history.

Why It Matters

Clean commit histories are critical for code maintenance, with studies showing developers spend 23% of their time reading code and 17% understanding existing work. A squashed, well-organized commit history reduces the time needed to understand what changes were made and why. Version control systems that prioritize clear history enable faster debugging using `git bisect` to identify problematic commits. Google and Microsoft both report that clean commit histories directly correlate with reduced bug introduction rates in their codebases.

Enterprise development teams, open-source projects like Linux and Kubernetes, and companies like GitHub itself mandate squashed commits in pull requests. Netflix's microservices architecture requires each service's commits to tell a coherent story, necessitating aggressive squashing practices. Facebook's Sapienz automated testing relies on clear commits to correlate code changes with test failures. These industry leaders recognize that squashing is not optional overhead but essential infrastructure for maintainable software.

Future version control systems are moving toward even stricter commit standards, with some platforms automatically squashing pull requests by default. Conventional Commits, a specification gaining industry adoption, pairs perfectly with squashing to create semantically meaningful commit histories. AI-powered code review tools increasingly analyze commit messages to understand intent, making clear, squashed commits vital for automated analysis. As codebases grow larger, the importance of pristine commit history only increases.

Common Misconceptions

A widespread misconception is that squashing deletes or loses code changes. In reality, squashing only changes the commit history representation; all code changes are preserved exactly as they were. Git stores the combined code changes in the squashed commit, so functionality is never affected. This misunderstanding leads some developers to fear squashing, when in reality it's completely safe for rewriting local history.

Many developers believe they can safely squash commits that have already been pushed to shared repositories. This is dangerous because squashing rewrites history, causing conflicts for other developers who have based work on the original commits. The golden rule is to only squash commits on personal branches before sharing them. If you accidentally squash published commits, a force-push can correct this, but it's disruptive and should be avoided through proper workflow discipline.

Another myth is that squashing should always reduce commits to exactly one. In fact, best practice is to create 'logical commits' that represent coherent feature pieces. A single feature might warrant 2-3 squashed commits if they represent distinct, reviewable changes. The goal isn't minimal commits but rather clean, understandable history where each commit represents intentional progress. Teams should balance cleanliness with preserving meaningful separation of concerns.

Common Misconceptions

Why It Matters

How It Works