How to Remove Unwanted Commits from Pull Requests: A Comprehensive Guide to Git Revert

Problem Context and Scenario Analysis

In Git collaborative development, developers often encounter situations where pull requests become polluted with accidental commits. Specifically, after creating a pull request, additional local commits are automatically included in the existing pull request, resulting in unrelated or erroneous changes. This scenario is particularly common among GitHub newcomers who are less familiar with branch management and commit propagation mechanisms.

From a technical perspective, a pull request is essentially a collection of commits from a branch. When new commits are made to the local branch and pushed to the remote repository, the corresponding pull request automatically updates to include these new commits. This explains why local commits made after creating a pull request can "pollute" the original pull request.

Core Solution: The Git Revert Approach

For commit pollution issues, the git revert command provides the most direct and effective solution. Unlike rebase methods that completely remove commits, revert safely eliminates unwanted changes by creating new "undo commits" that reverse the changes introduced by specified commits.

The complete operational workflow is as follows:

1. Switch to the target branch:

   git checkout <branch-name>

   Where <branch-name> is the name of the branch containing the polluted commits.

2. Execute the revert operation:

   git revert <commit-hash>

   Here, <commit-hash> is the hash of the commit that needs to be undone. Git automatically creates a new commit containing the inverse changes of the specified commit.

3. Force push to the remote repository:

   git push origin <branch-name> --force

   Since revert creates new commit history, the --force flag is required to overwrite the remote branch. As a safer alternative, consider using --force-with-lease, which checks if the remote branch has been modified by others before forcing the push.

Technical Principles Deep Dive

The working mechanism of git revert is based on differential calculation of commits. When executing git revert <commit>, Git performs the following operations:

• Analyzes the changes introduced by the specified commit
• Calculates the inverse operations of these changes
• Creates a new commit applying these inverse operations
• Preserves the original commit history record

The fundamental difference between this method and git reset lies in their approach to history: reset rewrites history by completely removing commits, while revert maintains complete historical records by adding new undo commits. This is particularly important in team collaboration environments, where rewriting shared history can cause serious conflicts in other developers' repositories.

Comparison with Alternative Methods

Besides the revert method, developers can also consider using interactive rebase:

git rebase -i HEAD~n

In the rebase interactive interface, mark unwanted commits as drop. This method completely removes specified commits and rewrites commit history. While it results in cleaner history, it requires extreme caution when used on shared branches, as it may affect other collaborators.

Selection criteria:

• Personal branches or branches not yet worked on by others: Suitable for rebase
• Shared branches or branches already pulled by others: Must use revert
• Need to completely hide certain changes: Use rebase
• Need to maintain complete operation records: Use revert

Practical Considerations

When performing revert operations, pay attention to the following key points:

Conflict Resolution: If the commit to be reverted has dependencies with subsequent commits, conflicts may occur during the revert process. In such cases, manual conflict resolution is required, followed by git revert --continue to complete the operation.

Permission Considerations: Some Git repository configurations may prohibit force pushes. In such situations, contact the repository administrator or consider creating a new pull request.

Multiple Reverts: The same commit can be reverted multiple times, but each operation creates a new undo commit. In complex scenarios, combining other Git commands may be necessary to organize commit history effectively.

Advanced Scenarios and Best Practices

For more complex situations, such as the branch synchronization issues mentioned in the reference article, adopt a systematic approach:

1. Ensure the main branch is synchronized with upstream:

   git checkout main
   git fetch upstream
   git reset --hard upstream/main

2. Rebuild the feature branch on a clean base:

   git checkout feature-branch
   git rebase -i main

3. Carefully examine the commit history to ensure only relevant changes are included

Prevention is better than cure. Establishing good Git workflows can effectively avoid commit pollution issues:

• Create separate branches for each feature
• Carefully review commit history before pushing
• Use git log --oneline --graph to visualize branch structure
• Regularly merge updates from the main branch into feature branches

Environment-Specific Problem Solving

As described in the reference article, Windows environments may encounter filename length issues that hinder branch switching operations. Solutions include:

git config --global core.longpaths true

Or enabling long path support in the Windows system. For severe environment compatibility issues, consider using Windows Subsystem for Linux (WSL) for a better development experience.

By mastering the correct usage of git revert, developers can effectively manage commits in pull requests, maintain clear project history, and improve team collaboration efficiency. This method ensures both operational safety and flexibility in handling unexpected situations, making it an essential skill for every Git user.