Squashing Commits in Git After Push: Principles, Methods, and Best Practices

Technical Background of Git Commit Squashing

In daily usage of distributed version control systems, developers frequently encounter challenges in commit history management. When multiple related code modifications are scattered across different commits, project history becomes lengthy and difficult to track. Git's commit squashing functionality can merge multiple consecutive commits into a single logically complete commit, which is significant for maintaining codebase clarity and maintainability.

Core Mechanisms of Interactive Rebasing

Git's interactive rebase command git rebase -i serves as the fundamental tool for commit squashing. This command allows users to reorder, edit, merge, or delete a series of commits. Its working mechanism is based on reconstructing commit history by creating a new commit sequence to replace the original commit chain.

Specifically for squashing operations, when executing git rebase -i origin/master~4 master, Git will:

1. Extract all commits from the 4th commit before origin/master to the tip of the current master branch
2. Open the default text editor to display the list of these commits
3. Allow users to specify which commits should be merged by changing pick to squash

Special Handling for Pushed Commits

Unlike squashing local unpushed commits, squashing commits that have been pushed to remote repositories requires additional considerations. Due to Git's distributed nature, remote repositories already contain the original commit history, and directly pushing squashed commits will cause history conflicts.

Common error scenarios during squashing operations include:

$ git rebase -i origin/master~4 master
# Not currently on any branch.
nothing to commit (working directory clean)

Could not apply 2f40e2c... Revert "issue 4427: bpf device permission change option added"
$ git rebase -i origin/master~4 master
Interactive rebase already started

This situation typically indicates that the rebase process encountered conflicts when applying a particular commit, or that the rebase operation is already in progress. Resolution methods include using git rebase --abort to abort the current rebase and then restarting.

Complete Operational Workflow

For safe squashing of pushed commits, the following standardized workflow is recommended:

First, determine the range of commits to be squashed:

git rebase -i origin/master~4 master

In the opened editor, mark commits to be merged as squash:

pick 2f40e2c Latest commit
squash a1b2c3d Second commit
squash d4e5f6g Third commit
squash h7i8j9k Fourth commit

After saving and exiting, Git will open the editor again to display the original messages of all squashed commits:

# This is a combination of 4 commits.
# The first commit's message is:
Latest commit

# The second commit's message is:
Second commit

# The third commit's message is:
Third commit

# The fourth commit's message is:
Fourth commit

At this point, the final commit message needs to be edited, typically preserving the description of main modifications while deleting or commenting out minor information.

Necessity and Risk Control of Force Pushing

Since squashing operations rewrite commit history, force pushing is necessary to update the remote repository:

git push origin +master

Using the + prefix instead of the --force option is a safer choice. The + prefix only force pushes the specified reference, while --force may affect all matching references, particularly when push.default is set to matching or multiple push destinations are configured.

Important verification steps before force pushing:

• Confirm that no other developers are currently working based on the current branch
• Notify relevant team members in advance in collaborative environments
• Consider performing such operations on feature branches rather than main branches

Comparison of Alternative Approaches

Besides the interactive rebase method, the approach using git reset --soft combined with new commits is also available:

git checkout my_branch
git reset --soft HEAD~4
git commit
git push --force origin my_branch

This method directly moves HEAD to the target position, preserves all changes in the staging area, and then creates a new commit. Although simpler to operate, it loses metadata information from the original commits.

Best Practice Recommendations

In actual project development, commit squashing should follow these principles:

Regarding timing selection, it's recommended to perform squashing when feature development is complete and ready to merge into the main branch, rather than frequently squashing during development. This maintains the integrity of development history while ensuring the cleanliness of the main branch.

Regarding message standards, squashed commit messages should:

• Clearly describe the overall purpose of the group of changes
• Include relevant Issue or task numbers
• When necessary, detail important technical decisions in the message body

Regarding team collaboration, establish clear commit strategies:

• Standardize squashing operation processes within the team
• Use protected branches to prevent accidental history rewriting
• Focus on the rationality of commit history during code review processes

Through systematic methods for managing and optimizing commit history, teams can collaborate more effectively while maintaining codebase maintainability and traceability.