Avoid the use of git revert

Sometimes you have a commit in your branch that you don’t want for some reason. In this case, you may be tempted to use git revert to undo the changes made by the commit. Solo developers sometimes use git revert like this when they are not aware that it’s completely ok to rewrite history and force-push in Git.

Some downsides to using git revert are as follows:

• You end up with a new commit that “undoes” what another commit did. What you really wanted was to not have the original commit’s changes in your history at all.
• It’s cluttery to have two commits that cancel each other out when you would rather have none.
• You have to write a commit message.

Although there are certainly times when git revert is called for, it’s best to avoid it especially in non-mainline branches or with commits that haven’t even been pushed yet.

So how do I avoid it?

If you need to remove a commit from your history, rebase interactively and simply remove the commit you don’t want.

What if rebasing interactively takes too much conflict resolution?

There are times when git revert is the quickest way to what you need. If your commits are really tangled and interdependent (aka not very atomic), then you may need to just bite the bullet and use git revert! There are exceptions to everything, right?