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
Really hard to take anything you say seriously when you use the entire aplhabet for your hexadecimal SHA1 examples.