Git revert vs reset What's the difference? |Video upload date:  · Duration: PT8M15S  · Language: EN

Clear comparison of Git revert and Git reset with examples when to use each and how to recover lost commits.

Welcome to the git choose your weapon guide. Both git revert and git reset can fix mistakes. One does it politely and leaves a trail for teammates to admire. The other runs around changing history and may cause a panic worthy of a group chat. Use the right tool and avoid awkward stand up meetings.

Quick summary you can read between meetings

In plain terms git revert creates a new commit that undoes the effects of a previous commit while git reset moves the branch pointer and optionally rewrites the index and working tree. Revert preserves public history and is safe on shared branches. Reset rewrites history and is best for local cleanup before you push.

What each command actually does

  • git revert makes a new commit that applies the inverse of a target commit. History stays linear and human readable. Your collaborators will thank you or at least not rage quit.
  • git reset moves HEAD to another commit. With modes that affect index and working tree you can change what is staged and what lives on disk. It rewrites history so use it on branches that are still private.

Reset modes and what they mean

  • --soft moves the branch pointer only. Good if you want to combine commits into a better commit message or tidy things up before you push.
  • --mixed moves the branch pointer and resets the index. Your working tree remains, but staged changes are cleared.
  • --hard moves the branch pointer and resets index and working tree. This one throws away uncommitted changes like it never cared about your late night edits.

Examples that you can paste into your terminal

git revert 

git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1

Safety and collaboration rules

If a commit has already been pushed to a remote prefer revert. Rewriting public history with reset usually forces a push and that can orphan commits and confuse collaborators. In other words be prepared for people to blame the git workflow and not read the README.

Rescue options when you panic

  • git reflog is your best friend after a scary reset. It records where HEAD has been so you can find lost commits and restore them with git checkout or another reset.
  • If you accidentally reset a public branch expect to coordinate a force push and explain why to your team. Apologies and a small cake might help.

Decision cheat sheet

  • Shared branch and visible commits choose git revert. Safe and polite.
  • Local cleanup before pushing choose git reset. Tidy history without nasty surprises for others.
  • Multiple surgical edits consider interactive rebase for rewriting a sequence of commits before anything is public.

Final git tips and best practices

  • When in doubt make a throwaway branch and try commands there first.
  • Use git reflog if something goes missing.
  • When you must rewrite public history be explicit with teammates and be ready to force push with care.
  • Remember that revert keeps history honest and reset gives you a fresh canvas. Both are valid tools depending on whether you want to avoid drama or curate perfection.

Now go forth and fix commits responsibly. And if you do break something at least make it a teachable moment.

I know how you can get Azure Certified, Google Cloud Certified and AWS Certified. It's a cool certification exam simulator site called certificationexams.pro. Check it out, and tell them Cameron sent ya!

This is a dedicated watch page for a single video.