git reset命令详解

开门见山，先抛出一张图，之后再细讲。 

 

首先，先解释下图中的一些名词。 

一.名词解释

1. Working Copy:当前工作目录下的文件，一般指，有修改，没有git add，没有git commit的文件

2. Index:也可以被认为是staging area（暂存区）,也就是使用git add添加后的文件,是一堆将在下一次commit中提交的文件，提交之后它就是当前 HEAD的父节点。

3. HEAD:指向当前branch最顶端的一个commit，也就是该分支最近一次commit后的节点

 

上图的上部分解释如下： 

当你第一次checkout一个新的分支，HEAD指向该分支上最近一次commit。它和index和working copy是一样一样的。

当你修改了一个文件，你的working copy不再和index和HEAD相同了，所以当文件有改动，它会标记这些文件。

然后，你执行git add命令，这条命令会将上面修改的文件缓存在index中，你的working copy和index相同了，而他们俩和HEAD不同了”。

当你执行git commit，Git创建了一个新的commit，HEAD这时指向这个新的commit，此时，HEAD & index & working copy又相同了

 

二.reset命令

git reset 命令格式为git reset [--soft | --mixed | --hard] [<commitId>]

是git中最常用的命令，但也是最危险，最容易被误用的命令。reset命令本身很简单，但是它的参数让人迷惑，主要的参数有soft、 mixed、hard,它们告诉Git，当执行reset时，要对index和working copy做什么。

s oft

--soft参数只告诉Git将其他的commit重置到HEAD，就仅此而已。index和working copy中的文件都不改变。

实例:

git reset --soft [commitId] 回退到某个版本，只回退了commit的信息。如果还要提交，直接commit即可

m ixed (默认参数)

--mixed 改变HEAD和index，指向那个你要reset到的commit上。而working copy文件不被改变。当然会显示工作目录下有修改，但没有缓存到index中。

h ard

--hard HEAD & index & working copy同时改变到你要reset到的那个commit上。这个参数很危险，执行了它，你的本地修改可能就丢失了。

注意： commitId是每次commit的id，可以通过git log来进行获取

 

三.加餐

1.恢复git reset —hard的误操作

有时候不小心通过git reset —hard将版本回退到之前的commit了。可以先通过 git reflog命令，找到要退回的commitId，然后通过命令git reset —hard commitId来恢复

 

2.git revert 和 git reset的区别 

a. git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。 

b. 在回滚这一操作上看，效果差不多。但是在日后继续merge以前的老版本时有区别。因为git revert是用一次逆向的commit“中和”之前的提交，因此日后合并老的branch时，导致这部分改变不会再次出现，但是git reset是之间把某些commit在某个branch上删除，因而和老的branch再次merge时，这些被回滚的commit应该还会被引入。

c. git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。

 

 参考：

https://blog.csdn.net/qq_22705681/article/details/89327791

https://www.cnblogs.com/0616--ataozhijia/p/3709917.html