[Advanced Git] Git Reset or Git Revert? Choose the Right Way to Undo

In the world of programming, Git is like an indispensable "time machine." It lets us travel back to any point in a project's history. But when you accidentally commit a silly mistake, a sensitive file, or simply want to clean up your commit history, which function of this time machine should you use?

The two most powerful options in Git are git reset and git revert. Both can "undo" changes, but they do so with completely different philosophies. Misunderstanding this difference can lead to lost code or breaking your team's history.

This article will help you master both, knowing exactly when to use git reset and when to use git revert.

Rewriting History with Git Reset 📜

Imagine your commit history as a chronicle. git reset is like a historian with the power to tear out the last pages and rewrite them. It doesn't create a new chapter to fix mistakes; it completely erases what was written.

git reset works by moving the HEAD pointer (and optionally the Staging Area and Working Directory) to an earlier commit. This means any commits after that point become "orphans" and will eventually be cleaned up by Git forever.

The Three Modes of Git Reset

git reset has three main modes, from gentle to "heavyweight":

1. git reset --soft <commit>: The gentlest 🟢

   • Action: Only moves the HEAD pointer to the specified commit.
   • Staging Area & Working Directory: Completely unchanged. All changes from the reset commits remain in the Staging Area (ready to be recommitted).
   • Example: You just committed 5 separate files but now want to combine them into a single tidy commit. Use git reset --soft HEAD~5, and those 5 commits disappear, but all their changes remain staged, ready for git commit -m "Super clean combined commit".

2. git reset --mixed <commit> (This is the default mode)

   • Action: Moves HEAD and cleans up the Staging Area.
   • Staging Area: Changes are removed from the Staging Area.
   • Working Directory: Unchanged. Your files remain, but in an "unstaged" state. You need to git add them again if you want to commit.
   • Example: You just committed the wrong file and want to undo that commit and review the file before adding and committing again.

3. git reset --hard <commit>: The heaviest 🔥

   • Action: Moves HEAD, cleans the Staging Area, and wipes out all changes in the Working Directory.
   • Staging Area & Working Directory: Both are reset to the exact state of the commit you reset to. Any uncommitted changes are gone forever.
   • Example: You realize everything you've done in the last 3 commits is a mistake and want to throw it all away. Use this command with EXTREME caution!

⚠️ Warning: NEVER use git reset (especially --hard) on commits that have been pushed to a shared branch like main or develop. Rewriting history that your teammates rely on will cause conflicts and chaos.

Adding an Appendix with Git Revert ✍️

If git reset is the one who rewrites history, then git revert is a transparent and responsible historian. Instead of tearing out the wrong pages, git revert adds a new page at the end, saying: "Page X had a mistake, and here is the correction."

git revert works by looking at an old commit, finding the changes in that commit, and creating a new commit with the opposite changes to neutralize the old one.

Why is Git Revert Safe?

• Doesn't change history: git revert doesn't delete or change any existing commits. It only adds to the history. This keeps the project history continuous, clear, and easy to follow.
• Collaboration-safe: Since history isn't rewritten, it's completely safe to use on shared branches. Your teammates just need to git pull to get the new revert commit, with no history conflicts.

How Git Revert Works

To undo a commit, simply run:

git revert <commit-hash-to-undo>

Git will automatically create a new commit that reverses the changes. A text editor will pop up for you to write a commit message for this undo action.

🤝 Ideal use case: You discover a bug caused by a commit that was pushed to main a few days ago. The safest and most professional way is to git revert that commit. Everyone will clearly see that a commit was undone and why.

Quick Comparison Table: Git Reset vs. Git Revert

Real-World Scenarios: What Should You Choose? 💡

• Scenario 1: "I just committed a .env file with passwords to my personal feature branch. I haven't pushed it yet!"

  • Solution: git reset. This is where reset shines.
  • git reset --hard HEAD~1 to erase that bad commit and the file from your Working Directory. Safe, fast, clean.

• Scenario 2: "A feature I just deployed to Staging (from the develop branch) caused a serious bug. That commit was pushed and others have already pulled it."

  • Solution: git revert. Absolutely do not use reset.
  • git revert <bad-commit-hash> and push this revert commit. The system is restored, and history remains clear.

• Scenario 3: "I've made 5 tiny, messy commits on my personal branch. I want to combine them into 1 commit before making a Pull Request."

  • Solution: git reset --soft.
  • git reset --soft HEAD~5 then git commit -m "One big, complete feature commit".

Conclusion: Master Both Git Reset and Git Revert

Choosing between git reset and git revert depends entirely on context: are you working on your personal history or the shared history?

• git reset is a powerful tool for cleaning up and fixing things on your own branch. Think of it as your personal eraser.
• git revert is the safe, professional tool for fixing mistakes on branches you share with others. Think of it as a public correction note.

Mastering both will not only help you avoid Git disasters, but also elevate you to a developer who manages version control professionally and responsibly. Happy time-traveling in the world of Git!