Git reset soft,hard,mixed the difference deep solution

GIT Reset command, seems to be confusing, so that misunderstanding, misuse. But in fact it shouldn't be so hard to understand, as long as you understand what the order is doing.

First, let's look at a few terms HEAD

This is the alias at the top of the current branch version, which is the current branch of your most recent commit Index

Index, also known as staging area, refers to a set of files that will be submitted next. He's the one who's going to be head's father. Working Copy

Working copy represents the file set Flow that you are working on

When you checkout a branch for the first time, head points to the most recent commit of the current branch. The set of files in the head (actually they are technically not files, they are BLOBs (a group), but for the sake of discussion we simplify to think that they are some files) and the set of files in index is the same, in working copy of the file set and head, The set of files in index is exactly the same. All three (Head,index (STAGING), working COPY) are in the same state, and Git is happy.

When you make a change to a file, Git senses the change and says, "Hey, the file has changed." Your working copy is no longer the same as Index,head. ", and then git marks the file as modified.

Then, when you execute a git add, it stages the file in the index, and Git says, "Hey, OK, now your working copy and the index area are the same, but they're different from the head area." ”

When you execute a git commit,git and create a new commit, then head points to the new commit, and index,working copy has exactly the same status as the head, and git happy again.

The following paragraph is an explanation of another bull man:

In general, the git Reset command is used to reset the current branch to another commit, and this action may have the same effect as index and work tree. For example, if your master branch (current checked out) looks like this:

-A-B-C (HEAD, Master)

Head and Master Branch tip are together, and you want to point the master to B instead of C, then you perform

git reset B to move Master branch to B that commit:

-A-B (HEAD, Master)      #-C is still here, but there's no branch pointing to it anymore

Note: Git reset and checkout are not the same. If you run git checkout B, then you get:

-A-B (HEAD)-C (Master)

Then head and Master branch are not at one point, and you enter detached head state. Head,work Tree,index all point to B, but Master branch still points to c. If at this point you execute a new commit D, then you get the following (of course this may not be what you want, you might want to create a branch bug fix):

-A-B-C (master)
       \
        D (HEAD)

Remember that git reset doesn't produce commits, it just updates a branch (branch itself is a pointer to a commit) and points to another commit (head and branch tip move consistently). What's left of the rest is only for index and work tree (working directory). Git checkout xxxcommit only affects head, if Xxxcommit and a branch tip are the same, then head and branch match, if Xxxcommit doesn't match any branch tip, Then git enters detached HEAD state

Reset

If you take a closer look at the reset command itself, you know that what it does is reset the head (the top of the current branch version) to another commit. Suppose we have a branch (the name itself doesn't matter, so we're simply called the "Super-duper-feature" branch), and the graphical representation is as follows:

If we do:

git reset HEAD

Nothing happens because we tell git to reset the branch to the head, and this is where it is now.

git reset head~1

When we execute the above command (Head~1 is the alias of "the Commit right before head", or put differently "head ' parent"), our branch will be as follows

If we execute git reset head~2, it means moving the HEAD down from the top commit to two earlier commits. Parameters Soft

The--soft parameter tells Git to reset head to another commit, but that ends there. If you specify the--soft parameter, git will stop there and nothing will change at all. This means that index,working copy does not make any changes, and all the changesets between the original head and the commit that you reset are placed in the stage (index) area.

2.hard

The--hard parameter will be blow out everything. It resets the head back to another commit (depending on the parameter of the ~), resets the index to reflect the head change, and resets the working copy to make it match exactly. This is a more dangerous action, destructive, and the data may be lost. If the data is lost and you want it back, then only use: Git reflog command. Makes everything match the commit you has reset to. All your local modifications will be lost. If we want to completely discard local modifications but do not want to change the commit that branch points to, then execute git reset--hard = git reset--hard HEAD. i.e. don ' t change the branch but get rid of all local changes. Another scenario is to simply move branch from one commit to another to keep the index/work zone in sync. This will indeed make you lose your job as it will modify your work tree.

3.mixed (default)

--mixed is the default parameter for reset, which is the parameter when you do not specify any parameters. It resets the head to another commit and resets the index to match the head, but that ends there. Working copy is not changed. All changes in the branch from original HEAD (commit) to the commit you reset will be saved as local modifications in working area (marked as Local Modification or untracked via git status), but not staged state, you can re-view and then make changes and commit