What is git merge --squash?
When you use git merge --squash, Git takes all the changes from the branch you're merging and combines them into a single new commit on your current branch, rather than preserving the individual commits or creating a merge commit.
Simple Example
Imagine you have:
- main branch with files A and B
- feature branch where you made 3 commits: Added file C Modified file A Fixed a bug in file B Normal merge:
git checkout main
git merge feature
This keeps all 3 commits in main's history.
Squash merge:
git checkout main
git merge --squash feature
git commit -m "Implemented new feature"
This creates ONE new commit on main with all changes combined.
Tips and Tricks
1. Verify Changes Before Committing
After squashing but before committing:
git status # Shows all staged changes
git diff --cached # Review what will be committed
2. Combine with Interactive Rebase
For even more control:
git checkout feature
git rebase -i main # Squash commits interactively
git checkout main
git merge feature # Now a fast-forward
3. Preserve Original Branch
If you might need the original branch:
git checkout -b feature-squashed
git merge --squash feature
git commit -m "Squashed version"
Practical Differences between --squash & --no-ff
Learn about --no-ff here.
Reverting:
--no-ff: You can revert the merge commit to undo all changes
--squash: You revert just the squash commit (same effect, but different metadata)
Blame tracking:
--no-ff: git blame will show original authors
--squash: git blame will show the squashed commit's author
Branch cleanup:
After --no-ff, the feature branch's history is preserved in main
After --squash, you might delete the feature branch since its history isn't in main
When to Use --squash vs --no-ff
Use --squash when:
You want to simplify history for small, focused changes where individual commits don't provide meaningful context. Ideal for:
- Short-lived feature branches (e.g., bugfixes, minor enhancements)
- Cleaning up "work-in-progress" commits before merging
- Contributions from external collaborators where you want one clean commit
- When team policy prefers linear history
Use --no-ff when:
You want to preserve branch topology for significant features where commit history matters. Ideal for:
- Long-running feature branches
- Major developments that took multiple commits
- When you need to track exactly which commits belonged to which feature
- When reverting entire features might be necessary
Common Pitfalls
- Lost commit messages: Squashing discards individual commit messages. Solution:
git merge --squash feature
git commit -m "Feature X: $(git log feature --oneline | head -1)"
Conflicts appear different: Resolving conflicts in a squash merge might be different than in a regular merge.
Can't easily revert: Reverting a squash merge reverts all changes at once, not individual commits.
Conclusion: Clean History with Git Merge --squash
git merge --squash is your go-to tool for maintaining a clean, readable Git history. By combining multiple commits into one coherent change, it makes your project history more approachable for team members and future maintainers.
Up next: git branch -a + git remote show origin – Inspecting remote branches
Daily advance GIT tips in your inbox—worth starting? Respond to my poll here🚀
For more useful and innovative tips and tricks, Let's connect on Medium
nice