这篇文章主要介绍了Git命令git-reset怎么使用的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇Git命令git-reset怎么使用文章都会有所收获，下面我们一起来看看吧。
git-reset的作用是重置当前分支的HEAD指针，将HEAD指针指向特定的状态。
使用概述
git reset [<tree-ish>] [--] <pathspec> git reset [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>] git reset (--patch | -p) [<tree-ish>] [--] [<pathspec>] git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [<commit>]
前三行reset命令的作用是将指定的<tree-ish>内容作为参考依据，然后把内容拷贝到目标的缓存区中。
<tree-ish>就是像树一样的东西，git中是有很多都能组成树的，比如commit树或者tag树。
最后一行reset命令的作用是将当前分支的HEAD指针指向<commit>，同时可以使用多种可选项来控制是否修改缓存区或工作区。
在以上所有的命令形式中，都是把<tree-ish>或<commit>默认作为HEAD指针。
git reset [<tree-ish>] [--] <pathspec>
该方法有如下规则：
会将与<pathspec>相匹配的路径资源在缓存区中重置成<tree-ish>中的状态。不了解<pathspec>是什么？
被提交到缓存区中的改动会被还原到工作区中。
举个?
假设项目中有一个coffee.txt文件，文件内容如下：
卡布奇诺纳瑞冰-19.9￥ 标准美式-14.9￥ 香草拿铁-19.9￥ 生椰爱摩卡-19.9￥ ...
我们使用git的tag命令将当前的版本标记成v1.0.0（这里使用tag标签作为）。
随后修改coffee.txt文件，修改内容如下：
卡布奇诺纳瑞冰-19.9￥ --> 卡布奇诺纳瑞冰-14.9￥ 标准美式-14.9￥ --> 标准美式-9.9￥ 香草拿铁-19.9￥ --> 香草拿铁-14.9￥ 生椰爱摩卡-19.9￥ --> 生椰爱摩卡-14.9￥ ...
变更了coffee.txt文件后，再使用git tag打上了v1.0.1标记。
如果此时想将coffee.txt文件还原成v1.0.0版本中的文件，就可以使用git reset命令并指定为v1.0.0，操作如下：
git reset v1.0.0 coffee.txt
使用VSCode查看缓存区的文件变动：
可以看到图中的右侧的代码改动对比，此时缓存区中的coffee.txt文件已经成功被重置成v1.0.0版本中文件的状态(规则1)。并且此时v1.0.1已经提交到缓存区中的变动也被还原到了工作树中(规则2)。
可以看出git reset命令与git add命令作用相反，一个是将指定的资源添加到缓存区，另一个则是从缓存区中移除。并且这个命令与git restore [--source=<tree-ish>] --staged <pathspec>具有相同的作用，对restore感兴趣的可以看看这篇文章。
上面说过了，在使用reset命令后，此时缓存区中文件内容是v1.0.0的，可以配合git restore命令将缓存区中的内容还原到工作区中然后进行修改：
git restore coffee.txt --staged
也可以根据需要选择还原工作区的内容：
git restore coffee.txt --worktree
git reset [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]
在上面的例子中每次进行reset和restore的都是想同的<pathspec>路径(coffee.txt)。因为该文件路径比较简单，所以每次操作都比较方便输入。但是在一些情况下，可能需要reset比较复杂的<pathspec>路径，比如项目目录层次较深，那么很可能需要输入一长串的<pathspec>路径，这样每次进行操作就会很麻烦，所以git提供了一个--pathspec-from-file选项，让我们能够直接指定一个文件，这个文件就包含了可能需要重复使用的<pathspec>路径。这里有更详细的用法。
该文件每一行都是一个<pathspec>，如果有多个<pathspec>使用换行符作为分隔。当然也可以使用--pathspec-file-nul让NUL作为每一个<pathspec>的分隔符。
git reset (--patch | -p) [<tree-ish>] [--] [<pathspec>]
交互式的选择<tree-ish>与缓存区之间的差异而产生的hunks。这些被选择的hunks将会撤销缓存区中的产生的修改。这里有更详细的--patch选项用法。
git reset [<mode>] [<commit>]
该命令会把当前分支的HEAD指针指向某个<commit>，然后由<mode>决定是否同时更新缓存区或工作区的内容。<mode>默认值是--mixed，且必须是以下几种：
--soft
工作区和缓存区中的文件变动都将被保留，然后将HEAD指针指向<commit>。
还是以咖啡菜单为?，假如第一次commit到仓库中的文件内容如下：
卡布奇诺纳瑞冰-19.9￥ 标准美式-14.9￥ 香草拿铁-19.9￥ 生椰爱摩卡-19.9￥ ...
然后做第二次commit操作，删除标准美式，增加生椰拿铁：
卡布奇诺纳瑞冰-19.9￥ -标准美式-14.9￥ +生椰拿铁-19.9￥ 香草拿铁-19.9￥ 生椰爱摩卡-19.9￥ ...
在commit后，修改卡布奇诺纳瑞冰的价格，添加到缓存区。再修改香草拿铁的价格，保留在工作区：
-卡布奇诺纳瑞冰-19.9￥ +卡布奇诺纳瑞冰-14.9￥ // 添加到缓存区中 生椰拿铁-19.9￥ -香草拿铁-19.9￥ +香草拿铁-14.9￥ // 保留在工作区 生椰爱摩卡-19.9￥ ...
此时我想保留工作区和缓存区做的改动，并且将HEAD指针指向第一次commit。这时可以使用--soft选项实现：
git reset HEAD^ --soft // 这里使用HEAD^表示上一个commit，同样也可以使用hash id
使用git log查看当前HEAD指针确实已经指向第一个commit，第二个commit被抛弃了：
同时所有的工作区和缓存区的改动都被保留了：
当前只有两次的commit，是为了方便演示--soft选项的作用。但是在实际开发中，我们可能会commit多次，尤其是在测试环境改几个BUG就要提交到发布平台，这样会导致很多无意义的commit。这时候就可以使用--soft选项，重置HEAD到指定的<commit>只保留一到两个重要的commit。
--mixed
重置缓存区，但是会保留工作区的内容，这是<mode>的默认值。
相信在理解了--soft作用后，理解--mixed不难，上面例子中如果是使用--mixed那么最终结果如下：
该选项会重置缓存区，但是保留工作区的改动，并将当前指针指向<commit>。
--hard
重置缓存区和工作区中的所有的变动，并且将指针指向<commit>。
--hard更加的简单粗暴，我们将--soft例子改为--hard来查看结果：
如图所示，工作区和缓存区的内容都被重置了。不止是如此，就连Untracked文件同样也会被删除。
--merge
该选项的作用，看字面意思就知道大概就是把当前分支和指定的<commit>进行合并，规则如下：
重置缓存区，任何已经添加到缓存区的改动都将被抛弃
如果<commit>和HEAD之间有文件存在不同（这个不同指的是文件被删除或者新增），那么将会把该文件重置成<commit>中的状态（新增或删除）。
如果<commit>和HEAD之间有文件存在不同（这个不同是指文件内容的不同），且此时工作区也存在未提交的改动，那么本次的reset将会被终止。
如果一个文件在<commit>和HEAD中完全相同，但是它的工作区存与缓存区存在着不同（也就是改动未提交到缓存区），那么该文件在工作区的改动在重置之后就会被保留。
我们举个例子来验证一下以上列出的规则，假设此时的咖啡店项目有如下的几个commit。
第一个commit和文件内容如下：
第一个commit中只有一个coffee.txt菜单文件，此时如果咖啡店引进了新品种开始卖果汁，那么就需要新增果汁菜单文件fruits.txt，于是就有了第二个commit：
此时我们做一些改动来验证1，2，4这几点的规则，改动后的文件如下：
首先修改coffee.txt文件，新增一款生椰拿铁咖啡，保留在工作区中。然后增加咖啡豆菜单文件beans.txt，将其添加到缓存区中。
假设因需求变动，咖啡豆菜单文件在缓存区中需要清除，果汁菜单文件需要删除，只有咖啡菜单中新增的生椰拿铁的改动需要保留。那么就可以使用git reset --merge将HEAD和commit-1进行合并，操作如下：
git reset --merge HEAD^
结果如下：
执行命令reset命令产生了如下效果：
将当前HEAD指针指向了commit-1
将缓存区中的beans.txt文件抛弃(规则1)
HEAD(commit-2)和commit-1中的fruits.txt文件存在不同(commit-2中新增fruits.txt)，所以会将fruits.txt删除(规则2)
coffee.txt文件新增生椰拿铁的改动被保留在工作区中(规则4)
再来验证一下第3点规则，假设咖啡店项目此时第一个commit如下：
接下去同样新增水果茶菜单，然后再修改coffee.txt文件，第二个commit如下：
然后在HEAD中再修改coffee.txt文件，删除掉标准美式品种：
此时，如果我们再使用git reset --merge HEAD^就无法再进行重置，该操作会被git终止(规则3)。并且控制台会进行报错提示：
--keep
该选参的作用和--merge相似，唯一的区别就是缓存区中被重置的会被保留在工作区中。
构造如下第一个commit：
改造第二个commit：
在HEAD中进行修改
使用git reset --keep命令：
从结果上来看，只有fruits.txt文件被删除了，beans.txt文件被重置回了工作区中。coffee.txt文件的改动也被保留了。
--[no-]recurse-submodules