Introduction

Squashing commits means rewriting history so multiple commits become one new commit. The most common way is interactive rebase, and the main thing to understand is that you should only do this on branches where rewriting history is safe.

Squash all commits on the current branch with interactive rebase

If you want to turn the entire branch history into one commit, start the rebase from the root commit:

git rebase -i --root

Git opens a list of commits. Leave the first commit as pick and change every later line from pick to squash or fixup.

Example:

pick a1b2c3d Initial work
squash d4e5f6g Add tests
squash h7i8j9k Fix edge case

When the rebase finishes, Git creates one new commit that contains the same final file state but a simplified history.

Squashing only the commits on a feature branch

In practice, many developers only want to squash the commits made since branching from main. A common workflow is:

git checkout feature/my-change
git rebase -i $(git merge-base main HEAD)

That rebases only the branch-specific commits, not the entire repository history. It is often the better choice when preparing a feature branch for review.

Updating the remote branch afterward

Because squashing rewrites commit hashes, a branch that was already pushed needs a force push:

git push --force-with-lease origin feature/my-change

Use --force-with-lease rather than plain --force. It refuses to overwrite the remote branch if someone else updated it since your last fetch.

What happens to commit messages

During a squash rebase, Git lets you combine or edit the commit message. If you use fixup instead of squash, Git discards the extra commit messages and keeps only the first one.

That is useful when you have cleanup commits such as "fix typo" or "review changes" that do not deserve separate history entries.

A non-interactive alternative

If the goal is simply "take everything on this branch since it diverged from main and make one new commit," a soft reset can be easier:

git checkout feature/my-change
git reset --soft $(git merge-base main HEAD)
git commit -m "Implement feature"

This leaves all changes staged as one new commit. It does not preserve the intermediate commit messages, but it is straightforward and avoids the rebase editor.

Common Pitfalls

The biggest mistake is squashing commits that other people have already based work on. Once you rewrite history and force-push, collaborators must reconcile their branches with the new commit graph.

Another issue is choosing the wrong base commit. If you rebase or reset from the wrong point, you may accidentally squash unrelated history.

Conflicts can also happen during squash rebase, especially if the branch contains many overlapping edits. Resolve the conflicts, stage the files, and continue with git rebase --continue.

Finally, make sure the final commit message is meaningful. Squashing is supposed to improve history, not replace many small useful messages with one vague message like "updates."

Before rewriting the branch, it is often worth running git log --oneline --graph so you can see exactly which commits will be affected. That quick check helps prevent history edits that are broader than you intended.

Summary

• Use git rebase -i --root to squash an entire branch history into one commit.
• Use git rebase -i $(git merge-base main HEAD) when you only want to squash the commits made on a feature branch.
• A soft reset plus a new commit is a simpler non-interactive alternative.
• Expect to force-push with --force-with-lease if the branch already exists on a remote.
• Rewrite history carefully and only on branches where collaborators will not be surprised.