Shulou(Shulou.com)06/02 Report--

This article mainly explains "the respective usage of the three modes of Git Reset hard,soft,mix". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "the respective usage of the three modes of Git Reset hard,soft,mix".

Sometimes, when we use Git, it is possible for commit to submit code and find that there is an error in the content of commit this time, so there are two ways to deal with it:

1. Modify the error content and commit again. 2. Use the git reset command to undo the wrong commit this time

The first method is straightforward, but commit records multiple times.

Personally, I prefer the second method. There is no need to keep the wrong commit.

So let's talk about git reset today. It can be summarized in one sentence.

Git-reset-Reset current HEAD to the specified state

It means that you can make the pointer HEAD point somewhere else. For example, we once commit is not very satisfied, we need to go back to the last Commit. So at this point, you need to point the HEAD pointer to the point of the last commit through reset.

It has three modes, soft,mixed,hard, the specific use of which is shown in the following picture.

Git regions and command relationships

These three patterns are understood and are helpful for using this command. Before you can understand these three patterns, you need to know a little bit about the basic flow of Git. As shown in the figure above, Git will have three areas:

Working Tree's current work area

The Index/Stage temporary storage area is different from the temporary storage area of the git stash command. Using git add xx, you can add xx to the near Stage

The history of Repository submission, even if the result is submitted with git commit

Save files to the Repository process

Here is a brief description of the process of saving files to Repository:

At first, the contents of working tree, index and repository (HEAD) are all the same.

Stage 1

When the contents of the folder managed by git are changed, the content of working tree will be inconsistent with that of index and repository (HEAD), and Git knows which files (Tracked File) have been changed and directly sets the file status to modified (Unstaged files).

Stage 2

When we execute git add, we add these changed file contents to the index (Staged files), so the contents of working tree and index are the same, but they are not the same as repository (HEAD).

Stage 3

After performing the git commit, all the changed file contents in the Git index are submitted to the Repository, and after a new commit node (HEAD) is established, the contents of the working tree, index and repository (HEAD) areas will be consistent.

Stage 4

Practical demonstration reset-hard: reset the stage area and working directory:

Reset-hard resets the contents of the stage area and working directory while resetting HEAD and branch. When you add the-hard parameter after reset, the contents of your stage area and working directory will be completely reset to the same content as the new location of HEAD. In other words, your changes without commit will be erased.

For example, you made some changes to the file after the last commit: add the modified ganmes.txt file to the stage area, and keep the modified shopping list.txt in the working directory

Git status

Initial state

Then you execute the reset and attach the-- hard parameter:

Git reset-- hard head ^

When your HEAD and the current branch cut to the previous commit, the new changes in your working directory and the new changes that have been add to the stage area also disappear:

Git status

Reset-- after hard head^

As you can see, after reset-hard, all the changes have been erased.

Reset-- soft: keep the working directory and put the new differences caused by resetting HEAD into the staging area

Reset-soft retains the contents of the working directory and staging area when resetting HEAD and branch, and puts the new differences caused by resetting HEAD into the staging area.

What is the "new difference brought about by resetting HEAD"? This is it:

Because HEAD moved from 4 to 3, and the contents of the working directory and temporary storage area were not cleaned up during the reset process, the changes in 4 became the new "working directory and HEAD difference" in the working directory after reset. This is the difference brought about by resetting HEAD as mentioned in the previous paragraph.

In this mode, the contents of the working tree working directory will be retained and will not be changed to the contents of all current git-managed folders;

Keep the contents of the index staging area so that the contents of the index staging area are consistent with those of the working tree working directory. Only the content changes in the repository need to be consistent with the reset target node, so the difference change set between the original node and the reset node will exist in the index staging area (Staged files), so we can directly execute git commit to submit the content in the index staging area to the repository. When we want to merge commit records that are not very meaningful between the "current node" and the "reset target node" (perhaps periodically and frequently), we can consider using Soft Reset to make the commit evolution line clearer.

So in the same case, it's the same: add the modified ganmes.txt file to the stage area, and keep the modified shopping list.txt in the working directory.

Initial state of git status

Suppose the change to the current commit is to add a new laughters.txt file:

Git show-statgit show-stat

If you execute at this time:

Git reset-- soft head ^

Then in addition to the HEAD and the branch2 it points to being moved to head ^, the changes to the commit at HEAD (that is, the laughters.txt file) will also be placed in the staging area:

After git status uses git reset-- soft head ^

This is the difference between-- soft and-- hard:-- hard clears the changes to the working directory and staging area, * while-soft retains the contents of the working directory and puts new file differences caused by retaining the contents of the working directory into the staging area.

Reset with no parameters (mixed): keep the working directory and empty the staging area

If reset takes no parameters, it defaults to the-- mixed parameter. Its behavior is to keep the working directory and clear the staging area. That is, changes to the working directory, contents of the staging area, and new file differences caused by reset will be put into the working directory. In short, "mixed all the differences in the working directory".

Take the same situation as an example:

Initial state of git status

Modified games.txt and shopping list.txt, and put games.txt in the staging area.

Git show-statgit show-stat

The laughters.txt file has been added to the latest commit.

At this point, if you execute reset with no parameters or with-- mixed parameters:

Git reset head ^ git reset-- mixed head ^

The contents of the working directory will be retained like-- soft, but the difference with-- soft is that it will empty the temporary storage area and put the files that differ between the original node and the reset node in the working directory. All in all, changes to the working directory, the contents of the temporary storage area and new file differences caused by reset will be put into the working directory.

After git statusgit reset head ^

Summarize the essence of reset: mobile HEAD and the branch it points to

In essence, although the instruction reset can be used to undo a commit, its actual behavior is not to undo, but to move the HEAD and "piggyback" the branch (if any) pointed to by the HEAD. In other words, the behavior of the reset instruction actually matches its literal meaning "reset": it is used to reset the HEAD and the position of the branch it points to.

Reset-- hard head ^ has the effect of undoing commit because it moves HEAD and the branch it points to to the parent commit of the current commit, thus having the effect of "undo":

Git reset

The history of Git can only look back, not the future, so moving HEAD and branch back can have the effect of withdrawing commit.

So in the same way, reset-hard can not only undo the submission, but can also be used to move HEAD and branch anywhere else.

Git reset-hard branch3git reset-hard branch3

Differences between the three modes of reset and usage scenarios:

-- hard: while resetting the location, reset the working Tree working directory, index staging area and repository directly to the contents of the target Reset node, so the effect seems to be equivalent to emptying the staging area and workspace.

-- soft: while resetting the location, the contents of the working Tree working directory and the index staging area are retained, so that only the contents in the repository are consistent with the reset target node, so the [differential changeset] between the original node and the reset node will be put into the index staging area (Staged files). So the effect seems to be that the contents of the working directory and the original contents of the staging area remain unchanged, except that all differences between the original node and the Reset node are placed in the staging area.

-- mixed (default): when you reset the location, only the content of the Working Tree working directory is retained, but the content changes in the Index staging area and Repository are consistent with the reset target node, so the differential change set between the original node and the Reset node is placed in the Working Tree working directory. So the effect seems to be that all the differences between the original node and the Reset node are put in the working directory.

Use the scene:

-- hard: (1) when you want to discard all current local changes, that is, remove all files from add to the temporary storage area and files in the workspace, you can execute git reset-hard HEAD to force the restoration of the content and status of the folder managed by git; (2) you really want to abandon all the commit after the target node (you may think that the commit submission between the target node and the original node is wrong, and all previous commit has problems).

-- soft: the [differential changeset] between the original node and the reset node will be placed in the index staging area (Staged files), so if our working directory has not changed any files before and has not add to the staging area, then after using reset-- soft, we can directly execute git commit to submit the content in the index staging area to repository. Why are you doing this? The use scenario for this is: if we want to merge commit records that are not of much significance between the "current node" and the "reset target node" (it may be submitted frequently and periodically, that is, when a function is developed, it is commit when a file is changed or added, which results in multiple commit points for a complete function, if you need to integrate these commit into a commit). Consider using reset-- soft to make the commit evolution diagram clearer. In summary, you can merge commit nodes using-- soft.

-- mixed (default): (1) after using reset-- mixed, we can directly execute git add to add the file contents of these changes to the index storage area, and then execute git commit to submit the contents of the Index storage area to the Repository. This can also achieve the effect of merging commit nodes (similar to the above-- soft merging commit nodes, except that git add is added to the temporary storage area) (2) remove all files ready to be submitted in the Index staging area (Staged files). We can execute git reset HEAD to Unstage all the files to be submitted that have been included in the Index staging area. (sometimes you can use the command when you find that add files are misplaced in the staging area). (3) commit submits some error codes, or unnecessary files are also commit, do not want to modify the error and then commit (because it will leave an error commit point), you can fall back to the correct commit point, and then all the differences between the original node and the reset node will be returned to the working directory, if there is a unnecessary file can be deleted directly, and then commit on the OK.

Thank you for your reading. the above is the content of "the respective usage of the three modes of Git Reset hard,soft,mix". After the study of this article, I believe you have a deeper understanding of the respective usage of the three modes of Git Reset hard,soft,mix, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.