Git: Squash Latest Commits
Use interactive rebase to combine the latest commits on your current branch into one commit. Commit or stash any uncommitted changes before you begin. These steps assume a linear history without merge commits.
| Command | Description |
|---|---|
git log --oneline | Review the latest commits and decide how many to combine. |
git rebase -i HEAD~N | Replace N with the number of latest commits to combine (at least two). |
git rebase -i HEAD~3 | For example, open the latest three commits in your editor. |
git rebase -i --root | Use this instead if you want to combine all commits, including the repository's first commit. |
Choose the Commits to Squash
The editor lists commits from oldest to newest, unlike the default log output. Keep pick on the first commit and change it to squash (or s) on each following commit you want to combine:
pick a1b2c3d Add initial feature
squash b2c3d4e Fix feature behavior
squash c3d4e5f Add feature tests Save and close the editor. When the commit message editor opens, replace the combined messages with the message you want for the final commit, then save and close it to finish. Use fixup instead of squash to discard a later commit's message.
If Conflicts Occur
Resolve the conflicts in the affected files, stage each resolved file with git add <file>, and run git rebase --continue. Repeat if more conflicts occur. To cancel the rebase and return to the original history, run git rebase --abort.
Verify the Result
Run git log --oneline to confirm that the commits have become one, and run your tests to check that the combined commit still works.
Squashing with rebase rewrites commit history. Coordinate with anyone using the branch before updating it on the remote:
git push --force-with-lease This is safer than --force because it rejects the push if the remote branch no longer matches your local remote-tracking reference. If it is rejected, inspect the remote changes rather than overriding them. Avoid rewriting shared or protected branches. If the commits were never pushed, use a normal git push.
Squash and Merge a Feature Branch into Master
To bring all changes from your current feature branch into master as one new commit, use git merge --squash. Unlike rebase, this leaves the feature branch's commits unchanged. First commit or stash any uncommitted changes, and make sure you are on the feature branch, not in detached HEAD mode.
In a Bash shell, save the current branch name before switching to master. Run these commands one at a time; if switching or pulling fails, resolve the issue before continuing. This example assumes the remote is named origin:
feature_branch=$(git branch --show-current)
git switch master
git pull --ff-only origin master
git merge --squash "$feature_branch" The squash merge stages the feature branch's combined changes but does not create a commit. If conflicts occur, resolve them and stage each resolved file with git add <file>. Do not use git rebase --continue for this workflow. Review the staged changes with git diff --cached and run your tests before committing:
git diff --cached
git commit -m "Add completed feature"
git push origin master The result is one new commit on master, containing the feature branch's changes that are not already on master. No force-push is needed. A squash merge does not record the feature branch as merged, so use a new branch for the next feature. If master is protected, use your hosting platform's pull request workflow with “Squash and merge” instead of pushing directly.