Undoing changes - Git Reset & Git Revert 
Tags: git, github, revert, reset
Published: 2021-04-26 11:41:16


When you're working on a large opensource project, it is quite obvious for developers to _create branches, add files and stage them for commits when they are ready etc_.

However, in some cases, you might realize that the changes that you made are **_not that good_** or the **_feature you just added isn't up to the mark_**. 
You modified some files, added and deleted a lot of lines from the code base, but **NOW you want to go back** and revert the changes.

Don't worry much because, Git has got your back!

##Git Revert

The preferred method of undoing shared history is **git revert**.
 A **revert** is safer than a **reset** because it will not remove any commits from a shared history. **_A revert will retain the commits you want to undo and create a new commit that inverts the undesired commit_**. This method is safer for shared remote collaboration because a remote developer can then pull the branch and receive the new revert commit which undoes the undesired commit.
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tte6mxh17q93t043h2b8.png)
###You should never **reset** a commit which is pushed to a public repo, as it can cause serious problems for other developers of the project.
Instead use `git revert`
```
git log
#This will show the previous commits and their hashes. Copy 6 char hash of initial commit.

git revert <hash of initial commit>
```
You can check by running 
```
git status 
git log 
```
##Git Reset
It is a versatile tool for developers to use.
`git reset` is used for undoing changes on a private branch/locally. It has three modes depending upon where you want to reflect changes in Git's internal state management mechanism's. Git has three such state managements: The Commit Tree (HEAD), The Staging Index, and The Working Directory.
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qlf4ifaqympu8arun0at.png)
##--soft
This is the safest reset mode.
--soft resets the head to <commit>, just like all modes do.
It **does not touch the index file or the working tree at all** and leaves all your changed files as "Changes to be committed", as git status would put it.
The Staging Index and the Working Directory are left untouched so changes are not lost in either places. Only Commit Tree is altered.
```
git log
#This will show the previous commits and their hashes. Copy 6 char hash of initial commit.

git reset --soft <hash of initial commit>
```
You can check by running 
```
git status 
git log 
```

##--mixed
This is the default operating mode.
--mixed has the following impacts:
1. The ref pointers are updated. 
2. The Staging Index is reset to the state of the specified commit.
**Any changes that have been undone from the Staging Index are moved to the Working Directory**(you can recover by `git add file-1`)
```
git log
#This will show the previous commits and their hashes. Copy 6 char hash of initial commit.

git reset <hash of initial commit>
```
You can check by running 
```
git status 
git log 
```


##--hard 
This is the most DANGEROUS option. Use only when you're sure that you want to delete your work.
--hard has the following impacts 
1. The Commit History ref pointers are updated to the specified commit.
2. The Staging Index and Working Directory are reset to match that of the specified commit. 
**Any changes made are lost and matches to the state of the specified commit**
```
git log
#This will show the previous commits and their hashes. Copy 6 char hash of initial commit.

git reset --hard <hash of initial commit>
```
You can check by running 
```
git status 
git log 
```
Here's summing up the three modes, where they render changes.
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i01cxriw3uzahxga0wxn.png)