When using Git for version control, accidentally committing incorrect code is common—such as submitting unfinished code, sensitive information (like passwords), or introducing critical bugs. In such cases, Git’s version rollback feature helps safely restore to a previous stable state. This article will guide you through the core methods to recover code from erroneous commits in a simple and understandable way.

I. First, Understand: Git’s Version History¶

Git records every code change with a “commit” record, each having a unique “ID” (hash value), e.g., a1b2c3d. Use git log to view these history records:

git log --oneline  # Simplify commit display to show only key info

Example output:

a1b2c3d (HEAD -> main) Buggy commit: Added password (10:00 today)
e4f5g6h Fixed homepage bug (9:30 today)
i7j8k9l Project initialization (18:00 yesterday)

Here, a1b2c3d is the hash of the most recent error commit, and e4f5g6h is the hash of the previous stable version.

II. Core Method: Safely Roll Back to a Specified Version¶

Git provides the git reset command for version rollback. Depending on your needs, there are three scenarios:

Scenario 1: Roll Back to the Last Commit (Undo the Most Recent Mistake)¶

Use Case: Only need to undo the most recent commit (e.g., a minor error with no subsequent code changes).
Command:

git reset --soft HEAD~1

• Explanation:
• HEAD~1 refers to “the commit before the current one” (~1 = 1 step back).
• --soft: Only roll back the commit history, preserving staged and working directory changes (no loss of uncommitted code).
• Result: The commit history reverts to the previous version; you can re-edit and resubmit.

Scenario 2: Roll Back to a Specific Commit (Known Target Hash)¶

Use Case: The error was not the most recent commit; need to revert to an earlier stable version.
Steps:
1. Find the target commit hash:
Use git log --oneline to check history and copy the first 7 characters of the target commit (e.g., e4f5g6h).

2. Execute the rollback command:

   git reset --hard <target-hash>

• Explanation:
  • --hard: Completely roll back the version, discarding all subsequent changes (including staged/workspace). Always back up uncommitted work before using this!
  • Example: For e4f5g6h, run git reset --hard e4f5g6h.

3. Verify the result:
   Check the current version with git log and confirm code status with git status.

Scenario 3: Roll Back a Pushed Erroneous Commit¶

Use Case: The error was already pushed to a remote repository (e.g., a shared branch).
Risk: Direct rollback overwrites others’ code—use with caution!
Steps:
1. First, roll back locally (as in Scenario 2):

   git reset --hard <correct-hash>

2. Force-push the rolled-back version (overwrite remote history):

   git push -f origin <branch-name>

• Explanation:
  • -f (force) overwrites all subsequent commits on the remote branch.
  • Only use if no team members are working on this branch; communicate with the team first!

III. Key Warnings¶

1. Distinguish reset parameters:
   - --hard: Complete rollback (loses all changes after the target commit).
   - --mixed: Default; rolls back the version and resets the staging area, preserving workspace changes (adjust commit content).
   - --soft: Only roll back commits, preserving staging and workspace (revert and resubmit).

2. Handling uncommitted changes:
   If there are uncommitted changes before rolling back, use git stash:

   git stash save "Save uncommitted changes"  # Stash changes
   git reset --hard <target-hash>            # Roll back version
   git stash pop                            # Restore stashed changes

3. Never use -f on shared branches:
   Force-push overwrites others’ code. For team collaboration, use git revert (creates a new commit instead of overwriting history) or coordinate with the team first.

IV. Summary¶

Version rollback is Git’s core error-recovery tool. Key steps:
1. Check history first: Use git log to confirm the target commit hash.
2. Choose the right parameter: Select --soft/--mixed/--hard based on how much history to preserve.
3. Be cautious with remote operations: Avoid -f in shared branches; use revert if collaboration is active.

With these methods, you can safely recover from errors and maintain reliable version control!