Have you ever made some revisions to your code, committed those changes, and then wished you could undo the changes you just committed? Perhaps you pushed up some code to a remote branch for a feature you are working on and then realized that you want to remove the changes and go in a different direction? In this article, I will cover how to undo the mistakes 😲 that we inevitably make as developers.
Reset vs. Revert
In order to properly explain this topic, it's important to understand the distinction and differences between reset and revert. Although they have similar-sounding names, there are slight nuances to be aware of when deciding which option to go with.
TL;DR
- Use reset if you have only made local changes and you do NOT have a remote branch.
- Use revert if you have a remote branch with commits and you want to undo a commit while still keeping things in sync and retaining the git history.
Git Reset
Syntax: git reset [--optional flag] <commit-hash>
The git reset command provides a way to reset a project back to a specified commit. Once a reset is applied, all the changes before the specified commit are no longer a part of the history for a branch.
Git reset is best used when you have only made local commits (i.e. not pushed up your changes to a remote branch) and you want to undo those changes.
Let's say we have a history log that looks like the image below and we want to undo the last two commits and go back to the third commit.
One way to do this is to run one of the two commands:
git reset 899679c (Requires you to locate the commit hash from the log)git reset HEAD~2 (Tells git to drop the last two commits)
Soft Reset
Running either command above is considered a "soft" reset. All this means is the code changes that were undone are now brought back to the working directory files. Or put another way, a soft reset removes the commit history but preserves the changes.
A soft reset can be helpful if, for example, you made some commits on the wrong branch, but you want to keep the work you did and move it over to a different branch. With a soft reset, the commits will be removed, but the revisions will be retained.
Hard Reset
In contrast to a soft reset is a "hard" reset where the changes that are undone are completely removed and the files are put back into a "clean" state. To perform a hard reset you would run a similar command to the syntax above, but you would pass in the --hard flag.
Examples of undoing the last two commits using a hard reset:
git reset --hard 899679cgit reset --hard HEAD~2
🚨 Warning: Performing a hard reset will eradicate your previous commits and your code revisions.
Hard resets are most beneficial when you want to completely undo a commit and you don't care about retaining the original code. I go with this option when I need to drop a commit so I can start fresh from a certain point in my work.
Image of git log after reset has been applied
Git Revert
Syntax: git revert <commit-hash>
The git revert command is similar to the reset command, in that they both "undo" commits. However, they are different in how they achieve this functionality. Whereas resetting eradicates the commits from git history, reverting will create a brand new commit (at the end of the git history) with the reverted code changes. When a revert is run, git will prompt you to add a new commit with a helpful message explaining what got reverted.
Image of commit message prompt after running git revert
Image of git log after revert has been applied
Reverting allows you to undo commits cleanly that have already been pushed to a remote branch. A good use case for reverting is if you're working with another team member on the same feature branch and you want to undo a commit you made without compromising the git history. Unlike the git reset command that has a "soft" and "hard" version, there is only one type of revert command.
Git revert is best used when you have a remote branch with commits already pushed up and you want to undo a commit while still keeping things in sync.
El Fin 👋🏽
Even though I don't find myself needing to undo commits very often, I find that it's nice to have an understanding of these commands so that you can leverage them whenever you need to correct any mistakes.
If you enjoy what you read, feel free to like this article or subscribe to my newsletter, where I write about programming and productivity tips.
As always, thank you for reading, and happy coding!
Resources
