Practical Methods for Squashing Commits with Merge Commits in Git History

Technical Background of Git Commit Squashing

In distributed version control systems, Git provides powerful branch management and commit history manipulation capabilities. During actual development, developers often need to squash multiple commits on a feature branch into a single clean commit to facilitate code review and project history maintenance. However, when commit history contains merge commits, traditional methods like git merge --squash may not be directly applicable, requiring more refined operational strategies.

Analysis of Commit History with Merge Commits

Consider the following typical development scenario: a developer makes multiple commits on a feature branch, then encounters conflicts when pushing changes to the remote branch. To resolve these conflicts, the developer merges changes from the main branch, manually resolves conflicts, and commits the merge. At this point, the commit history structure appears as follows:

  * D commit 3 (HEAD)
  * M merge
 /|
| * C commit 2
* | B commit on master
|/
* A (master)

In this history structure, commit 3 is the most recent commit, M is the merge commit, and commit 2 is an earlier commit on the feature branch. The goal is to squash these three commits into one while preserving the integrity of code changes.

Core Method: Interactive Rebase

When dealing with commit histories containing merge commits, the most effective approach is using Git's interactive rebase functionality. The specific operational steps are as follows:

1. Identify Rebase Starting Point: First, determine where the feature branch diverged from the main branch. In the above history structure, this point is commit A, the base commit on the main branch.
2. Execute Interactive Rebase: Run the command git rebase -i A, where A is the starting commit hash or reference for the rebase. This command opens an editor displaying a list of all commits from the starting point to the current HEAD.
3. Edit Rebase Instructions: In the opened editor, you will see content similar to:

pick B commit on master
pick C commit 2
pick M merge
pick D commit 3

Note that interactive rebase typically does not directly display merge commits but converts them into a series of linear commits. In practice, you might see commits B and C, but the merge commit M may not appear directly since the rebase process reapplies commits.

pick B commit on master
squash C commit 2
squash D commit 3

With this configuration, Git will combine the changes from C and D into the B commit, creating a new squashed commit.

Comparative Analysis of Alternative Methods

Besides the interactive rebase method, other approaches exist for handling commit histories with merge commits. One common method involves creating a temporary branch:

git checkout -b temp main
git merge --squash feature
git commit
git checkout feature
git reset --hard temp
git branch -d temp

This method creates a temporary branch from the main branch, then uses git merge --squash to compress all changes from the feature branch into a single commit, finally resetting the feature branch to this squashed commit. The advantage of this approach is relative simplicity, but drawbacks include loss of the original commit history structure and potential inability to handle complex merge scenarios properly.

In contrast, the interactive rebase method offers finer control, allowing developers to select which commits to squash while maintaining complete control over the conflict resolution process. This method is particularly suitable for scenarios requiring preservation of certain commit independence or handling complex merge histories.

Technical Points and Best Practices

When squashing commits in histories containing merge commits, several key technical points require attention:

• Conflict Resolution Strategy: Since rebase reapplies commits, conflicts previously resolved through merge commits may need re-resolution. It is advisable to understand the root causes of all conflicts before rebasing and prepare appropriate solutions.
• Commit Message Management: When squashing commits, Git provides an editor interface containing messages from all squashed commits. Carefully edit this commit message to ensure it accurately reflects all important change information.
• History Visualization Tools: Using commands like git log --graph --oneline to visualize commit history helps understand branch structure and merge relationships, providing clear context for rebase operations.
• Backup Strategy: Before performing any history rewriting operations, consider creating branch backups or using git reflog to record reference history, enabling recovery of the original state if operations go wrong.

Extended Practical Application Scenarios

The techniques discussed in this article apply not only to simple feature branch merging scenarios but also extend to more complex development workflows:

• Long-Term Feature Branch Maintenance: For feature branches requiring extended development, regularly squashing commits can reduce historical noise and improve code review efficiency.
• Open Source Project Contributions: When submitting pull requests to open source projects, clean commit histories are generally preferred by maintainers. The methods described here can optimize contribution quality.
• Team Collaboration Standards: Teams can establish commit history management standards based on interactive rebase to ensure consistency and readability of project history.

By mastering the technique of squashing commits in Git histories containing merge commits, developers can manage project history more effectively, improve collaboration efficiency, and maintain the cleanliness and maintainability of codebases. Although these advanced Git operations require a learning curve, once mastered, they become powerful tools in daily development work.