When working on a Git project, your commit history can quickly become cluttered with incremental commits like “fixed typo,” “minor change,” or “debug log removed.” While these commits show progress, they don’t always add value to the long-term history of your repository.
That’s where Git squash comes in. Squashing commits allows you to combine multiple commits into a single, cleaner one, making your Git history easier to read and maintain.
In this guide, we’ll cover practical ways to squash commits, how to do it with rebase and merge, when it’s the right choice, and examples to help you keep your Git history clean, professional, and easy to work with.
Table of Contents
What is Git Squash
“In Git, ‘squashing’ means merging multiple commits into a single one”.
Git doesn’t have a git squash command. Instead, you squash commits by using other commands, such as interactive rebase or merge.
When to Squash Commits
Git squashing is especially useful when a series of small git commits all belong to one long list of commits. Take the case of a project called TaskMate, a lightweight task management app. The first release, tagged v1.0, included core features: creating tasks and marking them complete. After that release, the team started working toward v2.0. Along the way, they added subtasks, improved search, and fixed a handful of early issues.
Before squashing, the commit history between v1.0 and v2.0 shows a trail of individual commits, “fix typo in search,” “update subtask UI,” “bugfix: completed state not saving,” and so on. While technically correct, the log trail is cluttered and harder to follow.
After squashing, all of those incremental git commits are combined into a single commit representing the v2.0 release. The result is a clear history where each major release is easy to identify and review.
How to Squash Commits in Git (Interactive Rebase and Squash Merge)
There are mainly two common ways to squash commits in Git:
- Interactive Rebase
- Squash Merge
Both help create a cleaner history, but they work slightly differently depending on your workflow. Let’s walk through a realistic scenario using a demo project called TaskMate, a simple task management tool, for the first two methods, and then we will discuss the third one.
Here’s the commit log after finishing work on a new feature branch (feature/reminders):
$ git log --oneline --graph --decorate
8c9a123 (HEAD -> feature/reminders) Added reminder popup styling
5a2d7ef Fixed bug in reminder scheduler
d0f4b21 Implemented reminder creation
71a6d2c (main) Released v1.0 stable
Instead of merging three small commits, we want to squash them into one clean commit before merging into main. So, let’s git squash the last 3 commits into one using interactive git rebase and merge:
1. Squashing Commits with Interactive Rebase
Interactive Rebase gives full control over how commits are combined and can be used when you want to Git squash the last 2 commits or more.
Step 1: Start Interactive Rebase
git rebase -i HEAD~3
This opens the last 3 commits in an editor:
pick d0f4b21 Implemented reminder creation
pick 5a2d7ef Fixed bug in reminder scheduler
pick 8c9a123 Added reminder popup styling
Step 2: Mark Commits to Squash
Keep the first commit as pick, and change the following ones to squash (or simply s), i.e., Change the 2nd and 3rd commits from pick → squash:
pick d0f4b21 Implemented reminder creation
squash 5a2d7ef Fixed bug in reminder scheduler
squash 8c9a123 Added reminder popup styling
Step 3: Write the New Commit Message
Git now prompts you to edit the combined message:
# This is a combination of 3 commits.
# The first commit’s message is:
Implemented reminder creation
# The following commit messages will also be included:
# Fixed bug in reminder scheduler
# Added reminder popup styling
We’ll clean this up:
Added reminder feature with bug fixes and styling
Save and close.
Step 4: Confirm Squash Result
git log --oneline --graph
a1b9f45 (HEAD -> feature/reminders) Added reminder feature with bug fixes and styling
71a6d2c (main) Released v1.0 stable
Once confirmed, the selected commits are rewritten into a single commit.
Result: your branch now contains one clear commit instead of several smaller steps.
2. Squashing Commits with Git Merge
Git also supports squashing the last n commits during a merge. Instead of merging every commit, you can combine all branch changes into one. This is essentially a Git merge squash that allows you to combine multiple Git squash commits into one.
Step 1: Checkout main
git checkout main
Step 2: Merge with Squash
git merge --squash feature/reminders
Git stages all changes from feature/reminders:
Auto-merging src/reminder.js
Auto-merging styles/reminder.css
Squash commit -- not updating HEAD
Step 3: Commit Manually
git commit -m "Add reminder feature"
Step 4: Push Changes
git push origin main
This applies all changes from feature/reminders to the current branch, but pauses before creating a commit. You then commit manually, producing one clean commit that represents the entire feature.
Result: the feature branch history is merged as one commit into main.
When NOT to Squash Commits
While Git squash commit is powerful, there are cases where you should avoid it:
- Shared Branches
- If your branch is already pushed and used by teammates, squashing rewrite history may cause conflicts.
- Use squash before pushing to remote, not after.
- Audit / Compliance Workflows
- In some projects, every commit is important for traceability. Squashing may remove the detailed audit trail.
- Learning & Debugging Purposes
- If commits show the evolution of thought or the debugging process, keeping them can be useful.
Thumb Rule:
Use squash for feature branches you control → avoid it on public/shared branches.
Pros and Cons of Using Squashing vs Merge Commits
Both git squash and git merge are valid workflows, but they serve different needs.
Pros of Squashing
- Cleaner commit history (one commit per feature).
- Easier to review changes in pull requests.
- Makes git log and git blame more readable.
Cons of Squashing
- Removes granular git commit history (harder to debug step-by-step).
- Risky if done on shared branches (rewrites history).
Pros of Merge Commits
- Keeps the full history intact (every commit preserved).
- Shows the exact sequence of changes and branch merges.
- Safer in collaborative projects (no history rewrite).
Cons of Merge Commits
- Creates a “noisy” history with many small commits.
- git log can become harder to follow in large projects.
Best Practice:
- Use Merge when you need to preserve history for traceability.
- Use Git Squash Commit for cleaning up feature branches.
Difference Between Squash, Rebase, and Amend
Although Git squash, rebase, and amend all deal with commit history, they serve different purposes:
| Command |
Purpose |
When to Use |
Example Command |
| Squash |
Combines multiple commits into one |
Clean up small commits before merging a feature branch |
git rebase -i HEAD~3 → mark commits as squash |
| Rebase |
Reapplies commits onto a new base commit (rewrites history) |
Keeping a linear history, syncing a feature branch with main |
git rebase main |
| Amend |
Updates the most recent commit |
Fix a typo, missing file, or update the commit message |
git commit –amend |
Conclusion
Git squash is a powerful way to keep commit history clean, professional, and maintainable. By combining multiple commits into one, you improve readability, simplify debugging, and make collaboration smoother. Use interactive rebase or squash merge based on your workflow, but remember not to squash on shared branches.
Git Squash Commits – FAQs
1. How to Squash the Last N Commits into One Commit in Git?
To squash the last N commits into a single commit, a developer can use Git’s interactive rebase feature. The process looks like this:
git rebase -i HEAD~N
This approach is often used before merging a feature branch into main, ensuring the project history stays clean and easy to follow.
2. Does squashing rewrite history?
Yes. Squashing rewrites commit history by combining multiple commits into one. The final code stays the same, but the history is rewritten.
3. Is it safe to squash commits in a shared branch?
No. It’s not safe to squash commits in a shared branch because it rewrites history and can cause conflicts for teammates. Always squash before pushing or only on your private feature branches.
4. When should you not squash commits?
Avoid Git Commit Squashing When:
- Working on a shared or team branch.
- You need a detailed commit trail for debugging or compliance.
- The commit history itself provides valuable context.