A Comprehensive Guide to Rolling Back the Last Two Commits in Git: From Scenario to Solution

Scenario Analysis

In daily use of the distributed version control system Git, developers often need to handle rollback operations for code commits, especially in collaborative development environments. Consider this typical scenario: Developer A makes commit #n, followed by Developer B with commit #n+1, and then Developer A makes two more commits, #n+2 and #n+3. If a defect is introduced in commit #n+2, Developer A needs to roll back the last two commits (i.e., #n+2 and #n+3) and continue development based on commit #n+1. While this seems straightforward, it can become complex in practice due to branch structures or merge commits.

Core Solution

According to the best answer, the most reliable method to roll back to a specific commit is using the git reset --hard <sha1_of_where_you_want_to_be> command. Here, <sha1_of_where_you_want_to_be> should be replaced with the full or partial hash of the target commit (i.e., commit #n+1). For example, if commit #n+1 has hash abc123, the command is:

git reset --hard abc123

This command moves the HEAD pointer of the current branch to the specified commit and resets the working directory and staging area to match that commit's state, effectively "rolling back" all subsequent commits.

Why git reset --hard HEAD~2 Might Fail

In the question, the developer tried git reset --hard HEAD~2, but it reverted to commit #n instead of #n+1. This is often due to merge commits or other non-linear structures in the branch history. Git's HEAD~2 syntax calculates based on the first-parent chain; if commit #n+1 is a merge commit or not in the direct ancestry, this command may not correctly identify the target. Thus, using commit hashes directly provides more precise control, avoiding the uncertainty of relative references.

Important Warnings and Risks

When using the --hard option, it is crucial to note its destructive nature: any uncommitted changes (including modifications in the working directory and staging area) will be permanently discarded and cannot be recovered through normal means. Before executing this command, it is recommended to check the current state with git status and use git stash to temporarily save uncommitted changes (if they need to be preserved). For example:

git stash
git reset --hard abc123
git stash pop  # Optional, to restore changes after rollback

This reduces the risk of data loss and ensures safety in the development process.

Supplementary Methods and Considerations

Besides git reset, other commands like git revert can also undo commits, but with a different mechanism: git revert creates a new commit to reverse changes, preserving history, and is suitable for public branches; whereas git reset directly rewrites history, making it more appropriate for local branches. In collaborative environments, if commits have been pushed to a remote repository, using git reset may cause conflicts and should be handled with care. Additionally, git log --oneline or git reflog can be used to view commit hashes and operation history, aiding in locating the target commit.

Practical Example and Code Demonstration

Assume we have the following commit history (output via git log --oneline):

def456 (HEAD) Commit #n+3
abc123 Commit #n+2
789012 Commit #n+1
345678 Commit #n

To roll back to commit #n+1 (hash 789012), execute:

git reset --hard 789012

After execution, the history becomes:

789012 (HEAD) Commit #n+1
345678 Commit #n

Developer A can then continue development based on this, fix the defect, and recommit. This process emphasizes precision and safety, serving as a key skill in Git workflows.