Today's Question:  What does your personal desk look like?        GIVE A SHOUT

git reset vs git revert

  sonic0002        2019-02-02 08:26:39       101,292        14    

When maintaining code using version control systems such as git, it is unavoidable that we need to rollback some wrong commits either due to bugs or temp code revert. In this case, rookie developers would be very nervous because they may get lost on what they should do to rollback their changes without affecting others, but to veteran developers, this is their routine work and they can show you different ways of doing that.

In this post, we will introduce two major ones used frequently by developers.

  • git reset
  • git revert

What are their differences and corresponding use cases? We will discuss them in detail below.

git reset

Assuming we have below few commits.

Commit A and B are working commits, but commit C and D are bad commits. Now we want to rollback to commit B and drop commit C and D. Currently HEAD is pointing to commit D 5lk4er, we just need to point HEAD to commit B a0fvf8 to achieve what we want. 

It's easy to use git reset command.

git reset --hard a0fvf8

After executing above command, the HEAD will point to commit B.

But now the remote origin still has HEAD point to commit D, if we directly use git push to push the changes, it will not update the remote repo, we need to add a -f option to force pushing the changes.

git push -f

The drawback of this method is that all the commits after HEAD will be gone once the reset is done. In case one day we found that some of the commits ate good ones and want to keep them, it is too late. Because of this, many companies forbid to use this method to rollback changes.

git revert

The use of git revert is to create a new commit which reverts a previous commit. The HEAD will point to the new reverting commit. 

For the example of git reset above, what we need to do is just reverting commit D and then reverting commit C. 

git revert 5lk4er
git revert 76sdeb

Now it creates two new commit D' and C', 

In above example, we have only two commits to revert, so we can revert one by one. But what if there are lots of commits to revert? We can revert a range indeed.

git revert OLDER_COMMIT^..NEWER_COMMIT

This method would not have the disadvantage of git reset, it would point HEAD to newly created reverting commit and it is ok to directly push the changes to remote without using the -f option.

Now let's take a look at a more difficult example. Assuming we have three commits but the bad commit is the second commit. 

It's not a good idea to use git reset to rollback the commit B since we need to keep commit C as it is a good commit. Now we can revert commit C and B and then use cherry-pick to commit C again. 

From above explanation, we can find out that the biggest difference between git reset and git revert is that git reset will reset the state of the branch to a previous state by dropping all the changes post the desired commit while git revert will reset to a previous state by creating new reverting commits and keep the original commits. It's recommended to use git revert instead of git reset in enterprise environment. 

Reference: https://kknews.cc/news/4najez2.html

GIT  GIT RESET  GIT REVERT 

Share on Facebook  Share on Twitter  Share on Weibo  Share on Reddit 

  RELATED


  14 COMMENTS


Anonymous [Reply]@ 2019-02-03 08:11:41

Really hard to take anything you say seriously when you use the entire aplhabet for your hexadecimal SHA1 examples.

Anonymous [Reply]@ 2019-02-04 21:52:35

No need for that

Anonymous [Reply]@ 2019-02-05 07:25:42

On the contrary, it’s a good decision, since those strings are never going to match any actual SHAs. Sort of like how it’s good practice to use “example.com” in example URLs since it’s been reserved for that purpose. Since we don’t have any reserved SHAs (at least that I’m aware of) it’s better to use illegal ones.

Alan [Reply]@ 2019-02-03 08:46:00

Given a lot of commits to cherry pick, the more efficient way to handle this is a basic interactive git rebase of the last X commits, and you delete the line(s) of the commit(s) to be deleted. Easy!

Anonymous [Reply]@ 2019-02-03 15:26:14

The drawback of force pushing is not that some commits get lost. It's that you change the history of a public repositor, breaking everyone else's local copy and forcing them to fix it on their side. It's such a bad idea that most tools and hosting services don't even allow it by default.

Anonymous [Reply]@ 2019-02-03 19:25:49
yes, good point
Anonymous [Reply]@ 2024-03-10 06:51:25

That's what --force-with-lease is for and that is perfectly okay to do, even in a production environment.

cmbuckley [Reply]@ 2019-02-04 12:02:25
There’s absolutely no reason to revert C, B and then re-apply C in your last example. You can simply revert B.
Ke Pi [Reply]@ 2019-02-04 19:41:20

yes, agreed

Anonymous [Reply]@ 2019-02-04 21:53:21

https://google.com

Anonymous [Reply]@ 2019-02-04 22:12:51

You can also use `git checkout a1b2c3d4 -- filename` to check out older revisions and then recommit those changes. It works great for shared state files that shouldn't be stored in version control but sometimes are

Anonymous [Reply]@ 2019-11-18 13:30:02

Had a hard time finding a good explanation of either revert or reset - then I found yours that not only explains each one, but compares and contrasts the two. Excellent article, thanks for the information!

Anonymous [Reply]@ 2020-03-27 18:40:17

Found this really helpful ! Thank you so much !

Ke Pi [Reply]@ 2020-03-28 05:29:48

thank you for liking it :)