What is a squash merge and when is it appropriate?
Learn what a git squash merge is, how git merge --squash collapses commits into one clean commit, and when it's appropriate versus harmful to history.
Expected Interview Answer
A squash merge combines all the commits of a feature branch into a single new commit on the target branch, collapsing the branch's messy history into one clean, atomic change.
Instead of preserving every intermediate commit (with 'fix typo' and 'wip' messages), git merge --squash stages all the branch's changes so you can create one coherent commit. It is appropriate when the individual commits have no lasting value and you want a linear, readable main-branch history — typical for pull-request workflows. The trade-off is that the granular history and true merge lineage are lost, so it is a poor fit for long-lived branches you plan to merge repeatedly.
- Produces a clean, linear main-branch history
- Hides noisy work-in-progress commits
- Makes each feature one revertible, atomic commit
- Simplifies git log and code archaeology
- Pairs well with PR-based review workflows
AI Mentor Explanation
A squash merge is like reporting an entire over as a single line in the summary — '14 runs, one wicket' — instead of narrating every wide, dot ball, and no-ball that led there. The messy delivery-by-delivery detail is dropped; only the clean net result joins the match story, which is perfect when the individual balls don't matter to the bigger scorecard.
Step-by-Step Explanation
Step 1
Finish the feature branch
Complete all work on the branch, however many messy commits it took.
Step 2
Switch to the target
Check out the branch you want to merge into, e.g. git checkout main.
Step 3
Squash-merge
Run git merge --squash feature — this stages all the branch's changes without committing.
Step 4
Write one commit
Run git commit to create a single, well-described commit representing the whole feature.
Step 5
Clean up
Delete the now-merged feature branch; note the squash commit has no merge link back to it.
What Interviewer Expects
- Defines squash merge as collapsing commits into one
- Knows git merge --squash stages but does not auto-commit
- Understands the trade-off: cleaner history vs lost granularity
- Can say when it's appropriate (PR features) and when not (shared long-lived branches)
- Notes that no true merge commit / lineage is recorded
Common Mistakes
- Thinking git merge --squash creates the commit automatically
- Squashing long-lived branches that will be merged again, causing conflicts
- Believing squash preserves individual commit authorship and dates
- Confusing squash merge with interactive rebase squashing
- Assuming a merge commit links the squashed branch to main
Best Answer (HR Friendly)
“A squash merge takes all the small, messy commits from a feature branch and combines them into one clean commit on the main branch. It's great for keeping project history tidy and readable, but you lose the step-by-step detail of how the feature was built.”
Code Example
git checkout main
# Stage all of feature's changes as one set, without committing
git merge --squash feature
# Create the single, well-described commit
git commit -m "Add user profile page"
# The feature branch is now fully merged in one commit; clean it up
git branch -D featureFollow-up Questions
- How does a squash merge differ from a regular merge commit?
- Why can squashing a long-lived shared branch cause repeated conflicts?
- What is the difference between git merge --squash and interactive rebase squashing?
- Does a squash merge preserve the original commit authors and timestamps?
- How do you revert a feature that was brought in via squash merge?
MCQ Practice
1. What does git merge --squash do by itself?
git merge --squash applies the combined changes to the working tree and index but leaves you to create the single commit manually with git commit.
2. When is a squash merge LEAST appropriate?
Because a squash merge records no real merge lineage, re-merging a long-lived branch later causes duplicate changes and conflicts.
3. What is lost when you squash merge?
Squashing collapses all intermediate commits into one, so the granular commit-by-commit history and true merge lineage are discarded.
Flash Cards
What is a squash merge? — Combining all commits of a branch into a single new commit on the target branch for a clean, linear history.
What does git merge --squash do alone? — It stages the combined changes but does not commit — you must run git commit yourself.
When is squash merge appropriate? — Short-lived PR feature branches whose intermediate WIP commits have no lasting value.
When to avoid squash merge? — Long-lived branches merged repeatedly, since no merge lineage is recorded and re-merges conflict.
Squash merge trade-off? — Cleaner, readable history at the cost of granular commit history and true merge lineage.