Git Revert vs Reset: When to Use Each

Git Revert vs Git Reset

Both git revert and git reset undo changes, but they work fundamentally differently and are appropriate in different situations.

git reset: Rewriting History

git reset moves the branch pointer backward, effectively erasing commits from the branch history.

# Undo last 2 commits, keep changes staged
git reset --soft HEAD~2

# Undo last commit, discard everything
git reset --hard HEAD~1

When to use reset:

• On private/local branches that have not been pushed
• When you want to clean up commits before pushing
• During interactive rebase workflows

Danger: If you reset commits that have been pushed to a shared branch, other developers will have divergent histories, causing merge conflicts and confusion.

git revert: Preserving History

git revert creates a new commit that is the inverse of the specified commit. The original commit stays in the history.

# Revert a specific commit
git revert abc1234

# Revert the last commit
git revert HEAD

# Revert without auto-committing
git revert --no-commit abc1234

When to use revert:

• On shared/public branches (main, develop)
• When you need to preserve history for auditing
• When other developers have already pulled the commits
• In production hotfix scenarios

Reverting Merge Commits

Reverting a merge commit requires specifying the parent:

# -m 1 means keep the first parent (usually main)
git revert -m 1 <merge-commit-hash>

Decision Flowchart

1. Has the commit been pushed to a shared branch? -> Use git revert
2. Is it a private/feature branch not yet pushed? -> Use git reset
3. Do you need to preserve audit history? -> Use git revert
4. Do you want to clean up messy local commits? -> Use git reset