Analysis of Git's 4-stage undo change command

Although git has been around for 12 years and there are countless articles about it online, there are still many people (including myself) who cannot fully grasp its functions. The following introduction is based on my personal understanding of git, and I may have made up some words that do not fully conform to git. The purpose is just to popularize git so that beginners can also have a general understanding of how to quickly get started with git. At the same time, in all the discussions below, we assume that only one branch is used, that is, the master branch. Although this approach does not conform to the git specification, in reality most users work directly on the master branch, so here we will not introduce more complex branches, nor involve the operation of tags, but only talk about how to roll back on the simplest master branch.

Basic Concepts

3 steps

Normally, our workflow consists of three steps, corresponding to the three arrow lines in the figure above:

 git add .
 git commit -m "comment"  
 git push

• git add . Put all files into the temporary storage area;
• git commit commits all files from the staging area to the local repository;
• git push pushes all files from the local repository to the remote repository.

4 districts

The reason why git is so confusing is that compared with traditional version management tools such as svn, it introduces the concept of a temporary storage area (Stage). This concept confuses many people. In fact, for beginners, we don’t need to care about how each area works in detail. It is enough to know that there are 4 areas:

• Working Area
• Stage
• Local Repository
• Remote Repository

5 states

The above 4 areas will generate a state after successfully entering each area, plus the initial state, a total of 5 states. Below we name these 5 states:

• Unmodified ( Origin )
• Modified
• Staged
• Committed
• Pushed

Check Modifications

Now that we understand the basic concepts, let's talk about how to undo a mistake. First, we need to understand how to check what was modified in each of the three steps, and then determine whether the modification was successful. The secondary commands for checking modifications are the same, all of which are diff, but the parameters are different.

Modified, not saved

 git diff

First, let's see how to check what changes have been made if we simply save the file in the browser but have not yet done git add . Let's take a random file to do an experiment:

We randomly added four numbers 1234 to the second line at the beginning of the file and saved it. At this time, the file has entered the modified state, but has not yet entered the temporary storage area. We run git diff, and the results are as follows:

 diff --git a/index.md b/index.md  
 index 73ff1ba..1066758 100644
 --- a/index.md  
 +++ b / index.md
 @@ -1,5 +1,5 @@
 ---  
 -layout: main
 +1234layout: main
 color: black
 ---  

The results of git diff tell us which files have been modified.

Saved but not submitted

 git diff --cached  

Now let's put the changes into the staging area. First execute git add . and then execute git diff. You will find that there is no result:

This means that the git diff command only checks the differences between our working area and the staging area. If we want to see the differences between the staging area and the local repository, we need to add a parameter git diff --cached:

 diff --git a/index.md b/index.md  
 index 73ff1ba..1066758 100644
 --- a/index.md  
 +++ b/ index .md
 @@ -1,5 +1,5 @@
 ---  
 -layout: main
 +1234layout: main
 color: black
 ---  

The difference we see at this time is the difference between the staging area and the local warehouse.

Submitted, not pushed

 git diff master origin/master

Now, we commit the changes from the staging area to the local repository and look at the differences. First execute git commit, then execute git diff --cached. There is no difference. Execute git diff master origin/master and you can see the difference:

Here, master is your local repository, and origin/master is your remote repository. master means the main branch. Since we are all working on the main branch, both sides are master here, and origin represents the remote.

Undo changes

Now that we know how to check various modifications, we can start trying out various undo operations.

Modified, not saved

If we have only modified the file in the editor but have not yet executed git add ., our file is still in the working area and has not entered the staging area. We can use:

 git checkout .

or

 git reset --hard  

to perform the undo operation.

As you can see, after executing git checkout ., the changes have been undone and git diff has no content.

A pair of antonyms

The antonym of git add . is git checkout .. After making the changes, if you want to take a step forward and put the changes into the temporary storage area, execute git add .. If you want to take a step back and undo the changes just now, execute git checkout ..

Saved but not submitted

You have executed git add . but have not yet executed git commit -m "comment". Now you realize your mistake and want to undo it, you can execute:

 git reset  
 git checkout .

or

 git reset --hard  

git reset only returns the changes to the state before git add ., which means that the file itself is still in a modified but unstaged state. If you want to return to the unmodified state, you also need to execute git checkout ..

You may have noticed that both of the above steps can be done with the same command git reset --hard. Yes, it is this powerful command that can completely restore your changes to their original state in one step.

Submitted, not pushed

Your hands were too quick. You executed both git add . and git commit . At this time, your code has already entered your local repository. However, you regret it. What should you do? Don't worry, there is still a way.

 git reset --hard origin/master  

It is still the git reset --hard command, but this time there is an additional parameter origin/master. As we mentioned above, origin/master represents the remote repository. Since you have polluted your local repository, get the code back from the remote repository.

Sent

Unfortunately, you acted too fast and did git add, git commit, and git push. Your code has already been put into the remote repository. If you want to restore it, fortunately, since your local repository and the remote repository are equivalent, you only need to restore the local repository first and then force push to the remote repository:

 git reset --hard HEAD^    
 git push -f

Summarize

We use the same command git reset --hard to undo the above four states. The usage of the first two states is even exactly the same, so as long as you master the usage of the git reset --hard command, you will never have to worry about committing errors again.