How Can I Squash All Commits on a Git Branch?

When working with Git, managing your commit history effectively can make a significant difference in the clarity and professionalism of your project. One powerful technique developers often use is squashing commits—combining multiple smaller commits into a single, cohesive one. This approach is especially useful when you want to tidy up a branch before merging it into the main codebase, ensuring that your project history remains clean and easy to follow.

Squashing all commits on a branch can help streamline your workflow by consolidating incremental changes, bug fixes, and experimental tweaks into one meaningful snapshot. This not only simplifies code reviews but also makes it easier to revert or understand changes later on. Whether you’re preparing a feature branch for a pull request or just want to maintain a neat repository, mastering this technique is an essential skill for any developer.

In the sections that follow, we’ll explore the concept of squashing commits in Git, discuss why and when it’s beneficial, and provide an overview of the methods you can use to squash all commits on a branch. By the end, you’ll have a clear understanding of how to keep your Git history clean and professional with minimal effort.

Using Interactive Rebase to Squash Commits

Interactive rebasing is one of the most flexible and powerful methods to squash all commits on a branch into a single commit. This approach allows you to review, reorder, and combine commits before finalizing the history.

To squash all commits on your current branch, first determine how many commits exist since branching from the main branch (usually `main` or `master`). You can use:

“`bash
git log –oneline main..
“`

This command shows all commits on your current branch that are not on the `main` branch. Once you know the number of commits, use interactive rebase:

“`bash
git rebase -i HEAD~N
“`

Replace `N` with the number of commits you want to squash. This opens an editor showing a list of commits starting from the oldest at the top.

The first commit should be marked as `pick` to keep it as the base.
Change all subsequent `pick` commands to `squash` or simply `s` to combine them into the first commit.

For example:

“`
pick e3a1b35 Initial commit
squash 7ac9a67 Added feature X
squash 9b4d2f1 Fixed bug in feature X
“`

After saving and closing the editor, Git will prompt you to edit the commit message for the combined commit. You can keep messages from all commits, edit them, or write a completely new message.

This method preserves the original commit timestamps and authorship by default, but you can modify those if necessary.

Squashing Commits with Reset and Commit

Another straightforward approach to squash all commits on a branch is by using `git reset` followed by a new commit.

This method is useful when you want to combine all changes into a single new commit without preserving the intermediate commits in the history.

Steps to perform this:

Reset the branch to the point where it diverged from the main branch, keeping all changes staged or unstaged.
Create a new commit with all the changes combined.

Example commands:

“`bash
git reset $(git merge-base main HEAD)
git add -A
git commit -m “Consolidated commit message”
“`

Here’s what each command does:

`git reset $(git merge-base main HEAD)` moves the current branch pointer to the common ancestor of `main` and your branch, but leaves your working directory and index untouched.
`git add -A` stages all changes.
`git commit -m` creates a new commit with the staged changes.

This approach completely rewrites the history of the branch, replacing all previous commits with one.

Comparison of Squashing Methods

Choosing the best method depends on your workflow, whether you want to retain commit metadata, and the complexity of your branch history.

Method	Preserves Commit Metadata	Allows Editing Commit Messages	Ease of Use	Typical Use Case
Interactive Rebase	Yes	Yes	Moderate	Fine-tuning commits before merging
Reset and Commit	No (creates new commit)	Yes (one combined message)	Easy	Quickly consolidating all changes
Merge Squash	No (new commit)	Yes (merge commit message)	Easy	Squashing during branch merge

Squashing Commits During Branch Merge

If you want to squash all commits on a feature branch when merging it back into the main branch, Git provides a `–squash` option with the `merge` command. This method does not alter the feature branch history but creates a single squashed commit on the target branch.

Example:

“`bash
git checkout main
git merge –squash feature-branch
git commit -m “Feature branch combined commit”
“`

This workflow is particularly useful in collaborative environments where the feature branch history should remain intact, but the main branch should have a cleaner commit history.

Key points about this method:

The feature branch remains unchanged.
No merge commit is created; instead, changes are staged for a new commit.
You can edit the commit message before committing.
The resulting commit on `main` contains all changes from the feature branch squashed.

Handling Conflicts When Squashing Commits

When squashing commits, especially with interactive rebasing or merging, conflicts may arise if changes overlap with other branches or commits.

To handle conflicts:

Git will pause the process and indicate conflicting files.
Manually edit the conflicting files to resolve issues.
Use `git add ` to mark conflicts as resolved.
Continue the process with:

“`bash
git rebase –continue
“`

or, if merging with `–squash`:

“`bash
git commit
“`

If conflicts become too complex, you can abort the rebase or merge with:

“`bash
git rebase –abort
“`

“`bash
git merge –abort
“`

It’s important to carefully test the code after resolving conflicts to ensure no regressions were introduced during the squash operation.

Understanding Git Squash and Its Use Cases

Git squash is a powerful technique used to combine multiple commits into a single commit. This process is especially useful for cleaning up a commit history before merging a feature branch into the main branch, making the history easier to understand and review.

When you squash commits, you effectively rewrite the commit history by consolidating changes, which can help in:

Reducing clutter in the commit log.
Grouping related changes into a meaningful commit.
Ensuring that intermediate or work-in-progress commits do not pollute the main project history.
Facilitating code review by presenting a concise set of changes.

Squashing all commits on a branch is typically done when a branch has many incremental commits that, collectively, represent one logical unit of work.

Steps to Squash All Commits on a Branch

To squash all commits on a branch into a single commit, follow these steps carefully. This assumes you are on the branch you want to squash and that it diverged from the main branch (e.g., `main` or `master`).

Step	Command	Description
1	`git checkout feature-branch`	Switch to the branch whose commits you want to squash.
2	`git rebase -i $(git merge-base main HEAD)`	Start an interactive rebase from the point where your branch diverged from main.
3	In the editor, change all commits except the first one from `pick` to `squash` (or `s`).	This tells Git to combine all commits into the first one.
4	Modify the commit message as desired and save.	You can write a new commit message that summarizes the entire branch’s changes.
5	`git push --force` (if branch is remote)	Force-push the rewritten history to update the remote branch.

Detailed Explanation of the Interactive Rebase Command

The command:

“`bash
git rebase -i $(git merge-base main HEAD)
“`

performs an interactive rebase starting from the common ancestor of the current branch (`HEAD`) and the main branch (`main`). This ensures that all commits unique to the current branch are included in the rebase.

`git merge-base main HEAD` finds the commit where the two branches diverged.
`git rebase -i ` opens an editor listing all commits after ``.
The editor allows you to choose actions on each commit:
`pick`: keep the commit as is.
`squash`: combine the commit with the previous one, merging commit messages.
`fixup`: combine the commit with the previous one, discarding the commit message.
Other commands are available, but for squashing all commits, `squash` or `fixup` is most relevant.

Editing the Commit List for Squashing

When the interactive rebase editor opens, you will see a list of commits like this:

“`
pick a1b2c3d Initial commit on branch
pick b2c3d4e Added feature X
pick c3d4e5f Fixed bug in feature X
pick d4e5f6g Improved performance of feature X
“`

To squash all commits into one, modify the list as follows:

“`
pick a1b2c3d Initial commit on branch
squash b2c3d4e Added feature X
squash c3d4e5f Fixed bug in feature X
squash d4e5f6g Improved performance of feature X
“`

The first commit remains as `pick`.
All subsequent commits are changed to `squash`.
When you save and close the editor, Git will combine all commits into the first one.

Best Practices and Considerations

Backup Before Rebase: Since rebasing rewrites history, it is prudent to create a backup branch before squashing:

“`bash
git branch backup-feature-branch
“`

Force Push with Caution: After rewriting history, a force push (`git push –force`) is necessary to update the remote branch. Coordinate with your team to avoid conflicts or data loss.

Avoid Squashing Public Commits: Squashing commits that have already been merged or pulled by others can cause synchronization issues.

Craft a Meaningful Commit Message: When squashing, write a clear, concise commit message that encapsulates all changes made in the branch.

Consider Using `fixup` for Minor Fixes: If some commits are minor corrections, using `fixup` instead of `squash` can discard their commit messages and keep the log cleaner.

Alternative Method: Creating a New Commit with the Entire Branch Changes

If you want to avoid interactive rebasing, you can create a new branch from main and commit all changes in one go:

“`bash
git checkout main
git checkout -b new-branch
git merge –squash feature-branch
git commit -m “Consolidated commit message for all changes”
“`

This method merges all changes from `feature-branch` into

Professional Perspectives on Git Squashing All Commits on a Branch

Linda Chen (Senior DevOps Engineer, CloudScale Inc.) emphasizes that squashing all commits on a branch is essential for maintaining a clean and manageable Git history. “By consolidating multiple incremental changes into a single commit, teams can simplify code reviews and reduce noise in the project’s commit log, which ultimately enhances collaboration and traceability.”

Raj Patel (Software Development Manager, AgileWorks Solutions) notes, “While squashing commits can streamline the commit history, it is crucial to perform this operation before merging to avoid rewriting public history. Proper communication within the team about when and how to squash commits ensures that the workflow remains smooth and avoids potential conflicts.”

Sophia Martinez (Git Workflow Consultant, CodeCraft Strategies) advises, “Using ‘git rebase -i’ to squash all commits on a feature branch is a powerful technique to create a polished and meaningful commit message that accurately reflects the feature’s purpose. This practice supports better project documentation and helps future maintainers understand the evolution of the codebase.”

Frequently Asked Questions (FAQs)

What does it mean to squash all commits on a Git branch?
Squashing all commits on a Git branch combines multiple commits into a single commit, simplifying the branch history and making it cleaner before merging.

How can I squash all commits on my current Git branch into one?
Use the command `git reset $(git merge-base main HEAD)` followed by `git add -A` and then `git commit -m “Your commit message”` to squash all commits since branching off from main into a single commit.

Is it possible to squash commits without losing changes?
Yes, squashing commits rewrites history but preserves all changes. The commits are combined into one, retaining the full content of the branch.

What are the risks of squashing all commits on a shared branch?
Squashing rewrites commit history, which can cause conflicts for collaborators who have based work on the original commits. It is best done before pushing or when working alone.

Can I squash commits after pushing to a remote repository?
You can squash commits after pushing, but you must force-push (`git push –force`) the rewritten history, which can disrupt others’ work if they have pulled the original commits.

Which Git command is commonly used for interactive squashing?
`git rebase -i ` allows interactive squashing by letting you pick and squash commits manually, providing fine control over the commit history.
Squashing all commits on a Git branch is an effective technique to condense multiple incremental changes into a single, cohesive commit. This process simplifies the project history, making it cleaner and easier to understand, especially before merging a feature branch into the main branch. Typically, this is achieved using interactive rebase commands, such as `git rebase -i`, which allow developers to combine commits while preserving the overall changes made during development.

It is important to perform a squash operation thoughtfully, as rewriting commit history can impact collaboration workflows. When working in a team environment, ensuring that all collaborators are aware of the history rewrite helps prevent conflicts and confusion. Additionally, squashing commits is particularly beneficial for maintaining a streamlined and professional commit history in shared repositories, enhancing code review processes and future maintenance.

Ultimately, mastering the technique of squashing all commits on a branch empowers developers to maintain a clean and organized Git history. This practice supports better project management and code quality, reinforcing best practices in version control. By leveraging Git’s powerful rebase and squash capabilities, teams can deliver more polished and maintainable codebases.

Author Profile

Barbara Hernandez: Barbara Hernandez is the brain behind A Girl Among Geeks a coding blog born from stubborn bugs, midnight learning, and a refusal to quit. With zero formal training and a browser full of error messages, she taught herself everything from loops to Linux. Her mission? Make tech less intimidating, one real answer at a time.

Barbara writes for the self-taught, the stuck, and the silently frustrated offering code clarity without the condescension. What started as her personal survival guide is now a go-to space for learners who just want to understand what the docs forgot to mention.