When to Use git reset vs git revert: A Practical Guide for Safe Code Rollbacks

During iterative development, developers often need to undo mistaken commits; beginners may panic while experienced engineers calmly revert changes using Git.

The two primary commands for rolling back are git reset and git revert, each with distinct behavior.

git reset

Consider a repository with four commits: A and B are correct, C and D are erroneous, and HEAD points to D.

Moving HEAD back to commit B (a0fvf8) discards C and D locally: git reset --hard a0fvf8 After the reset, HEAD points to B, but the remote repository still points to D. Pushing without force fails, so a forced push is required: git push -f This approach loses the history of C and D, which may be undesirable, and many companies forbid using git reset for rollbacks.

git revert

git revert

creates new commits that undo the changes of specified commits while preserving the original history.

To revert the example, first revert D then C (newer to older):

git revert 5l4ker
git revert 76sdeb

This produces new commits D' and C', keeping the original erroneous commits visible.

For many erroneous commits, reverting each individually is inefficient. A batch revert can be performed with: git revert OLDER_COMMIT^.NEWER_COMMIT This keeps the bad commits in history and moves HEAD forward, allowing a normal git push without force—an approach encouraged in enterprises.

Complex scenario with an intermediate bad commit

If an erroneous commit sits in the middle of a series (e.g., A‑B‑C‑D where C is bad), resetting to A would also discard the good commit C. Instead, reset to the commit before the bad range, then cherry‑pick the good commit back:

git reset --hard A
git cherry-pick C

In summary, git reset rewrites history and can cause loss of later commits, while git revert safely creates new commits that undo changes, preserving the original history and avoiding forced pushes.