Git Reset Introduction

This article edited from: http://guibin.iteye.com/blog/1014369 http://hi.baidu.com/tiger_tnt/blog/item/ A0464ffa6a8115d9b58f314d.html http://web.mit.edu/~mkgray/project/silk/root/afs/sipb/project/git/git-doc/ Git-reset.html
First, the basic article in the general use of Git, if you find that the wrong will not want to staging file add into the index, want to rollback cancellation, you can use the command: git reset head <file&gt ..., while git add finished, Git will also make the appropriate prompts, such as: reference

# Changes to is committed: # (use "git Reset head <file> ..." to Unstage) # new File:Test.scala

git reset [--hard|soft|mixed|merge|keep] [<commit> or head]: Resets the current branch (reset) to the specified <commit> or head (default, If you do not display the specified commit, the default is head, the most recent commit, and it is possible to update index and working directory according to [mode]. The value of mode can be hard, soft, mixed, merged, and keep. The meanings and effects of each pattern are described in detail below.  A).--hard: Reset (reset) index and working directory, any changes in working directory since <commit> have been discarded and the head is pointed to <commit>. A concrete example, assuming there are three commits, Git ST:

Commit3:add test3.c commit2:add test2.c commit1:add test1.c

After you perform git reset--hard head~1, show: Head are now at Commit2, run git log

Commit2:add test2.c Commit1:add test1.c

Run Git St, without any change B). The contents of--soft:index and working directory are not changed, just point head to <commit>.  The effect of this pattern is that after execution, all changes since <commit> will be shown in git status "Changes to be committed". A concrete example, assuming there are three commits, Git ST:

Commit3:add test3.c commit2:add test2.c commit1:add test1.c

After performing git reset--soft (default) head~1, run git log

Commit2:add test2.c Commit1:add test1.c

Run git status, the test3.c is in registers and ready to commit.   That's when git commit commits it. When using Git for collaborative development, we often need to send our own modifications to the patch, but in the process of modifying the code we have made many submissions, how to generate the patch from the initial code state to the final code state. The following features should be described in response to this situation. Let's say we git the branch in the Software warehouse as follows: A-->b-->c That means our code changes from state A to State B, commits once, and then modifies to state C for a commit. At this point we are sure that the changes from a to C are correct, no longer need State B, and that the change from a to C generates a patch sent to others. If you pack directly to generate two path, then how to generate a patch, then you need Git-reset command. First create a tag for state A, assuming that the name is a, then execute Git-reset--soft a so that our software warehouse becomes a State B and state C has been deleted, but the current code is not changed, or State C code, then we do a commit, The software warehouse looks like this: the code for A--&GT;D State D and State C is exactly the same, except that the name is different.  Now you can generate a patch package for someone else. C). --mixed: Reset index only, but not reset working directory. This mode is the default mode, which uses mixed mode when it is not shown to tell git reset mode. The effect of this pattern is that changes to files in working directory will be preserved, not discarded, but will not be marked as "Changes to be committed", but reports that have not been updated will be made. The report reads as follows: Quote unstaged changes after reset:m Test.scala M test.txt
D).--merge and--keep are not used much, as illustrated in the following example.   Two, common examples below are some typical scenarios for git reset: A) rollback Add Manipulation Reference $ edit (1) $ git add frotz.c filfre.c $ MAILX (2) $ git reset (3) $ git pull Git://info.ex Ample.com/nitfol (4)
(1) Edit file frotz.c, filfre.c, make some changes and add changes to index (2) To view the message, find someone wants you pull, some changes need you to merge down (3) However, you have messed up the index, because the index with head The commit does not match, but you know that the things that are about to pull will not affect the FROTZ.C and filfre.c that have been modified, so you can revert the changes to these two files.  After revert, those changes should still be in working directory, so git reset is done. (4) Then, after performing the pull, automatic merge,frotz.c and filfre.c these changes are still in working directory.
(B) Rollback of last commit reference $ git commit ... $ git reset--soft head^ (1) $ edit (2) $ git commit- A-c Orig_head (3)
(1) When submitted, you also found that the code did not submit complete, or you want to edit the submitted comment, perform git reset--soft head^, so that working tree and reset before the same, do not make any changes.  head^ the most recent commit before the head. (2) Modify the file under Working tree (3) and resubmit it using the comments, authors, dates, etc. of the commit before reset. Note that when the git reset command is executed, git copies the old head to the file. Git/orig_head, you can use Orig_head to refer to this commit in the command. The-a parameter in the commit command means telling git to automatically put all the modified and deleted files into the stage area, and the new files that are not tracked by Git are not affected. In the commit command,-c <commit> or-c <commit> means to submit the information in the committed commit object (author, submitter, note, timestamp, etc.), the meaning of this commit is very clear, Add all the changed files to stage area and resubmit with the last submit information.
(C) Roll back several recent commits and put these several commits on the branch called topic. Reference $ git Branch Topic/wip (1) $ git reset--hard head~3 (2) $ git checkout Topic/wip (3)
(1) You have submitted some commits, but at this point you find that these commits are not mature enough to enter the master branch, but you want to branch these commit changes on the new one.  So the git branch command was executed and a new branch called TOPIC/WIP was established on the current head. (2) then roll back the last three submissions on Master branch. Head~3 points to the current HEAD-3 commit commit,git reset--hard head~3 deletes the last three commits (delete head, head^, head~2) and points the head to head~3.
D permanently delete the last few commit references $ git commit ... $ git reset--hard head~3 (1)
(1) The last three commits (i.e. head, head^ and head~2) Submit a problem and you would like to permanently delete these three commits.
E) rollback merge and pull operations reference $ git pull (1) auto-merging nitfol CONFLICT (content): Merge CONFLICT in N Itfol Automatic merge failed;  Fix conflicts and then commit the result. $ git reset--hard (2) $ git pull. Topic/branch (3) updating from 41223 ...  To 13134 ... Fast-forward $ git reset--hard orig_head (4)
(1) Pull down some updates from origin, but there's a lot of conflict, and you don't have the time to settle these conflicts, so you decide to pull again when you're free. (2) because the pull operation generated a conflict, so all pull down changes have not been submitted, still stage area, in which case git reset--hard and git reset--hard head meaning the same, that is, clear index and working  Something that was messed up in the tree.  (3) Merge the Topic/branch into the current branch, this time there is no conflict, and the merged changes are automatically submitted. (4) But at this point you also found that it is too early to merge Topic/branch, so decided to roll back the merge, perform git reset--hard orig_head rollback just the pull/merge operation. Description: Before you perform git reset, Git puts the head of the reset in the. git/orig_head file, which is referenced in the command line using Orig_head. Similarly, when performing the pull and merge operations, Git puts the head in the Orig_head before the action is performed in case of a rollback operation.
(F) Rollback of the merge or pull in the contaminated working tree reference $ git pull (1) auto-merging nitfol merge made by Recursiv   E. Nitfol | +++++----... $ git reset--merge orig_head (2)
(1) Even if you have changed some of your working tree locally, you can safely git pull if you know that the content that will be pull will not cover the contents of your working tree. (2) Git after pull, you find this pull down the changes are not satisfied, want to roll back to the pull before the state, from the previous introduction know that we can perform git reset--hard orig_head, but this command has a side effect is to empty your working Tree, that is, discard the changes that you have not add locally. To avoid discarding the contents of the working tree, you can use git reset--merge orig_head, noting that--hard is replaced with--merge so that you can avoid removing working tree on rollback.
G the interrupted workflow is often the case in actual development: you are developing a large feature, at which point an urgent bug needs to be repaired, but the contents of the working tree are not yet formed and are not enough to commit. But you have to switch the other branch to fix the bug.  See the example below to quote $ git checkout feature; # You were working in ' feature ' branch and $ work work; # work got $ git commit-a-M "Snapshot WIP" (1) $ git checkout Master $ fix fix $ git commit; # commit with                                       Real log $ git checkout feature $ git reset--soft head^. # go back to WIP State (2) $ git reset (3)
(1) This time belongs to the temporary submission, so casually add a temporary comment.  (2) This reset deletes the WIP commit and sets the working tree to the State prior to submitting the WIP snapshot. (3) At this point, the Uncommit changes,git reset when the "snapshot WIP" Submission is still left in index will clean up the status of index as it has not yet submitted "snapshot WIP" to facilitate subsequent work.
(H) Reset a separate file assuming that you have added a file to the index, but then do not intend to submit the file, you can use git reset to remove the file from the index.                           Reference $ git reset--frotz.c (1) $ git commit-m "commit files in Index" (2) $ git add frotz.c (3)
(1) Remove the file frotz.c from index, (2) Submit the file in index (3) and add FROTZ.C to index again
(I) retain working tree and discard some previous commits suppose you are editing some files and have submitted them and continue to work, but now you find that the current content in working tree should belong to another branch, It has nothing to do with the previous commit.  At this point, you can open a new branch and keep the contents of the working tree.                            Reference $ git tag start $ git checkout-b branch1 $ edit $ git commit ... (1) $ edit $ git checkout-b branch2 (2) $ git reset--keep start (3)
(1) This time, the changes in the BRANCH1 have been submitted.  (2) found at this time, the previous submission does not belong to this branch, at this time you create a new BRANCH2, and switch to the BRANCH2.  (3) At this point you can use the Reset--keep to remove the commit after start, but keep working tree unchanged. Third, advanced articleGrammargit reset [q] [<commit>] [--] <paths&gt git reset (--patch |-p) [<commit>] [--] [<paths>] Git re Set (--soft |--mixed |--hard |--merge |--keep) [-Q] [<commit>]DESCRIPTION

In the ' the ' and second form, copy entries from <commit> to the index. In the third form, set the current branch head to <COMMIT>, optionally modifying index and working tree to Ma Tch. The <commit> defaults to head into all forms. git reset [q] [<commit>] [--] <paths>

This form resets the index entries for all <paths> to their state at <commit>. (It does not affect the working tree, nor the current branch.)

This means so git reset <paths> is the opposite of git add <paths>.

After running git reset <paths> to