Git重置命令--git reset用法总结

git reset 是Git最常用的命令，也是最危险最容易误用的命令之一。

一.git reset的用法

git reset有两种用方法：

git reset [-q] [<commit>] [--] <path>
git reset [--soft | --mixed | --hard | --keep | --merge] [-q] [<commit>] 

说明：
"[]"里面的内容为可选项，可以省略；
< commit >表示引用或者commit ID，如果省略，相当于使用HEAD；
path前面使用两个连续的短线（减号），是为了避免引用（后者commit ID）与路径（文件）名相同而发生冲突；
git reset命令能重置工作区的内容，但是不会影响未跟踪的文件。

1.1 第一种用法（包含路径path）

不会重置引用，也不会改变工作区，只是用提交状态下的文件path，替换暂存区里的文件,一般用于取消git add的提交。

1.2 第二种用法（不使用路径path）

这种用法会重置引用，并且根据参数的不同，重置暂存区或者工作区。

对照上图(图片来源：《git权威指南》，图片不是很清楚，注意图片中圆圈的数字)，执行git reset命令根据参数的不同，可以执行下面的一个或者多个动作：
(1).替换引用的指向，引用指向新的ID
(2).替换暂存区（index就是暂存区）。替换后，暂存区和引用指向的目录树一致
(3).替换工作区。替换后，工作区与暂存区相同

1.2.1 参数 --hard

git reset --hard <commit>

会执行上面的（1）、（2）、（3）

1.2.2 参数 --soft

git reset --soft <commit>

会执行操作（1）。即：只改变引用指向，不改变暂存区

1.2.3 参数 --mixed

git reset --mixed <commit>
等同于：git reset <cmomit>

如果不使用参数时，默认使用的就是–mixed参数
这个参数会执行操作(1)和(2),即：更改引用的指向和置换暂存区，不更改工作区。
command：git reset
用HEAD指向的目录树重置暂存区，工作区不受影响，相当于对git add的反向操作。引用没改变，是因为原来就是指向HEAD的，相当于没重置。
git reset HEAD等同于 git reset

1.3 总结说明

重置命令的一个用途是修改引用（如master）的游标指向。
在./.git/目录下有一个HEAD文件，使用cat ./.git/HEAD查看文件内容，发现HEAD是指向一个引用refs/heads/xxx(xxx是分支名，如master)，重置命令（reset）并没有改变HEAD的指向，改变的是分支游标的变更，HEAD始终指向refs/heads/xxx，但是因为分支游标的改变，所以在用git log 查看时，发现HEAD指向一个新的提交了。这一点是git reset和git checkout的区别，git checkout改变的是HEAD的指向，分支的游标并没有改变。

二.git reset --hard后如何恢复

不小心执行git reset --hard 命令后，暂存区、工作区和引用都变成了节点。想要恢复到最新的节点，还是使用git reset --hard 命令（commit为想要恢复的节点），如果你还记得那个节点，那么就很简单了。但是，现实情况是，我们大锁不知道commit ID，那么怎么找呢？
首先想到的是git log 命令，但是，你会发现，git log只显示了之前的提交，这是因为–hard参数会更改引用的指向，所以后面的提交记录都“消失”了。
Git为我们提供了另外一个命令：git reflog命令，这个命令会输出引用指向的变迁，通过这个命令可以找到之前的commit ID，然后再次使用git reset --hard 命令来恢复。

参考文献

本文是《Git权威指南》的读书笔记，详细内容参考第七章。