Join the AI Workshop to learn more about AI and how it can be applied to web development. Next cohort February 1st, 2026
The AI-first Web Development BOOTCAMP cohort starts February 24th, 2026. 10 weeks of intensive training and hands-on projects.
Squashing is the process of combining multiple commits into a single commit. It’s a powerful technique for cleaning up your commit history.
Why Squash Commits?
When working on a feature, you might make many small commits: “fix typo”, “trying this”, “ok now it works”, “oops forgot a file”. While committing often is good practice, these messy commits aren’t valuable in your final history.
Squashing lets you combine all those commits into one clean commit with a meaningful message like “Add user authentication feature”.
How to Squash with Interactive Rebase
git rebase -i HEAD~nReplace n with the number of commits you want to squash. This opens an interactive editor where you can mark commits with s (squash) to combine them with the previous commit.
Squashing in GitHub Pull Requests
GitHub can automatically squash commits when merging a Pull Request. Instead of seeing all individual commits, you get one commit and can write a detailed commit message during the merge process.
This eliminates commits that diverged from the head of the branch you’re merging to, including any reverted changes.
When to Squash: Different Scenarios
Working Alone on Your Own Repository
You have complete freedom. If you made several commits while experimenting and now want a cleaner history, go ahead and squash. What matters is the end result.
Working on a Feature Branch
Before merging to main, you can squash your commits into a single commit. Benefits:
- Easier to revert the entire feature if needed (just revert one commit)
- Cleaner git log
The downside is more philosophical: you worked hard on detailed commits, and now all that work becomes one commit. The proof of your iterative process is gone.
If you care about showing your daily progress (like GitHub’s contribution graph), squashing will reduce your visible activity.
Alternative: Keep the history intact when merging and use tags to mark states you might want to revert to.
Working with Team Members
If you and teammates worked on a feature branch together, squashing becomes problematic:
- Attribution: The squash commit shows only one author, making it look like one person did all the work
- Git blame: Tools like
git blamebecome useless for understanding why specific code decisions were made - Knowledge loss: If someone asks about code you squashed, you might not know the answer because a teammate wrote it
Consider keeping individual commits to preserve everyone’s contributions and maintain useful metadata.
Squashing on Remote Branches
Avoid squashing on remote branches that others are working on. If teammates already pulled the code, rewriting history will cause conflicts.
If something went wrong (like forgetting to squash before pushing), learn from it and find ways to prevent it in the future rather than risking breaking everyone’s local copies.
Conclusion
Squashing is useful in many situations, but use it with judgment. Different scenarios call for different approaches—there’s no one-size-fits-all answer.