Introduction

To squash two non-consecutive commits in Git, the normal solution is interactive rebase. You reorder the commits so the two target commits become adjacent, then mark the later one as squash or fixup. The important part is that squashing rewrites history, so it is safest before the commits are widely shared.

Why Non-Consecutive Squashing Needs Reordering

Git can squash adjacent commits naturally during rebase, but it cannot directly squash two commits that have other commits between them without first changing the commit order.

So the workflow is:

1. start an interactive rebase that includes both commits
2. move the commit lines so the target commits are adjacent
3. mark the later one as squash or fixup
4. complete the rebase and resolve conflicts if needed

That is the standard and most controlled approach.

Start an Interactive Rebase

Suppose your history looks like this, newest first:

1E  newer commit
2D  keep
3C  target to squash
4B  keep
5A  target to squash into

Start a rebase from before the older target commit:

git rebase -i A^

Git opens an editor with something like:

1pick A target commit one
2pick B keep
3pick C target commit two
4pick D keep
5pick E newer commit

Reorder and Mark for Squash

Move the second target so it appears right after the first one, then change its command.

1pick A target commit one
2squash C target commit two
3pick B keep
4pick D keep
5pick E newer commit

Or use fixup if you want to keep only the first commit message:

1pick A target commit one
2fixup C target commit two
3pick B keep
4pick D keep
5pick E newer commit

That tells Git to combine C into A after reordering the sequence.

Handle Conflicts Carefully

Reordering history can create conflicts, especially when the commits between the two targets touched the same code.

If Git stops with conflicts:

git status

Resolve the files, stage them, then continue:

git add path/to/file
git rebase --continue

Repeat until the rebase completes.

squash Versus fixup

Use:

• 'squash when you want to combine the commit messages'
• 'fixup when you want to discard the later commit message and keep the earlier one'

In practice, fixup is often cleaner when the later commit is just a correction or follow-up change that should never have had its own message in the final history.

When Not to Do This

If the commits have already been pushed and other people may have based work on them, squashing them rewrites public history. That is not automatically forbidden, but it requires coordination.

If the branch is shared, ask whether the cleaner history is worth the disruption. Often the answer is:

• yes for a private feature branch before merge
• no for a branch others already depend on heavily

If you do rewrite pushed history, you will typically need a force push:

git push --force-with-lease

Use --force-with-lease, not plain --force, because it is safer in collaborative work.

Make a Safety Copy First

Before complex rebases, it is wise to create a backup branch:

git branch backup-before-squash

That gives you an easy way back if the rebase goes wrong or if you realize afterward that a different history shape would have been better.

Common Pitfalls

The most common mistake is trying to squash non-consecutive commits without first reordering them in the interactive rebase plan. Another is rewriting history on a shared branch without coordinating with the team. Developers also use squash when they really wanted fixup, then waste time editing commit messages that should simply have been discarded.

Summary

• Use git rebase -i to squash non-consecutive commits.
• Reorder the commits so the two targets become adjacent.
• Mark the later one as squash or fixup.
• Resolve conflicts and continue the rebase as needed.
• Be cautious when rewriting history that has already been shared with others.