How to Revert Pushed Commits in Git: 4 Methods Compared

In daily development, developers often push erroneous code to a remote repository or need to roll back to a previous version. The author describes a scenario where untested optimizations were pushed but must be removed to accommodate a new requirement on an important project.

1. Manual File Comparison (Not Recommended)

If the erroneous changes are small, you can compare the current commit with the target commit (e.g., "help文档提交") using your IDE's "Compare Versions" feature (Ctrl+click two commits). Then manually delete the unwanted code. This works for simple changes but becomes impractical for complex or configuration-heavy codebases.

"Such operation is highly discouraged, but if you don't know Git, it's the easiest way to understand."

2. git revert (Recommended for Single Commits)

Right-click the erroneous commit in the history and choose "Revert". Git automatically creates a new revert commit that undoes the changes. Push this revert commit to the remote to complete the rollback. This method is safe because it preserves history and leaves an audit trail.

"revert is equivalent to automatically performing a version rollback and leaving a change record, which is very safe. This is also highly recommended by experts in the comments."

Limitation: revert only undoes one commit at a time. For dozens or hundreds of commits, repeated reverts are tedious and clutter history.

3. Create a New Branch from the Target Commit (Recommended for Many Commits)

Right-click the commit you want to return to and select "New Branch". This creates a branch at that point, preserving the original branch while giving you a clean starting point. It avoids generating many revert commits.

"Creating a branch only adds a branch, preserving the original version and allowing safe rollback without excessive revert records. However, use cautiously because excessive branching creates management overhead."

4. Reset Current Branch to Target Commit (Unsafe, Use with Caution)

Right-click the target commit and choose "Reset Current Branch to Here". Four options appear:

Soft : Keeps your working changes and staged files.

Mixed : Keeps working changes but unstages staged files.

Hard : Resets working directory and index to the selected commit; all changes (committed and uncommitted) are lost.

Keep : Resets committed changes but preserves uncommitted local changes.

The author selects hard. After reset, the erroneous commits disappear locally. To update the remote, you must force push ( Force Push ) because the local history has diverged. Note that protected branches (e.g., master) may reject force pushes.

After force push, the remote shows only the target commit ("help文档") and the three erroneous commits are gone.

The article concludes by implying that the choice depends on context: revert for safety and single commits, new branch for bulk rollback, reset+force push only when history rewrite is acceptable and branch is unprotected.