Git - 版本穿梭 reset 命令常用三个参数及实际应用场景(--hard / --soft / --mixed)

前言

本文会大量提到工作区 / 暂缓区 / 版本库及版本穿梭命令，如果你还不了解请先学习。

首先，依次会介绍版本穿梭 reset 命令的可选参数 --hard / --soft / --mixed 概念，后面会假设场景给出 什么场景情况适合用什么参数 。

hard

重置索引和工作树，自 以来对工作树中的跟踪文件所做的任何更改都将被丢弃。它会触碰暂缓区和工作区， 重置暂缓区和工作区并在本地库移动 HEAD 指针。

Resets the index and working tree. Any changes to tracked files in the working tree since are discarded.

soft

它完全不接触索引文件或工作树(但像所有模式一样，将头重置为 )。这使得所有更改的文件都像 git status 所说的那样 “要提交更改”。它不会触碰暂缓区和工作区，仅仅在本地库移动 HEAD 指针。

Does not touch the index file or the working tree at all (but resets the head to , just like all modes do). This leaves all your changed files “Changes to be committed”, as git status would put it.

mixed

重置索引，但不重置工作树，即保留更改的文件，但不标记为提交，并报告尚未更新的内容。这是默认操作。它不会触碰工作区，重置暂缓区并且会在本地库移动 HEAD 指针。 注意，如果指定了 -N，则删除的路径将标记为要添加的意图。

Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action. If -N is specified, removed paths are marked as intent-to-add.

假设场景

假如，我们历史版本库中有 4 个版本存在，然后从工作区 git add 添加到暂缓区 3 个文件，如下图所示当前场景：

注意，此时工作区与暂缓区都不 “干净” ，也就是都有状态存在。

---

一、我要回到 V0.1 版本，重置工作区与暂缓区(A/B/C文件与工作区状态我都不想要了)：

此时 --hard 非常合适。

$ git reset --hard [index]

因为 --soft 不会参与工作区与暂缓区，所以 A.java / B.java / C.java 与工作区状态都会保留，这与场景相悖。

再者 --mixed 不会参与工作区，所以 A.java / B.java / C.java 虽然被重置了，但工作区状态没有被重置。

---

二、我要回到 V0.2 版本，不重置工作区与暂缓区(A/B/C文件与工作区状态我还有用)：

此时 --soft 非常合适。

$ git reset --soft [index]

因为 --hard 会参与工作区与暂缓区，所以 A.java / B.java / C.java 都会被重置，这与场景相悖。

再者 --mixed 会参与暂缓区，所以工作区状态虽然保留了，但暂缓区却充值了。

---

三、我要回到 V0.3 版本，只保留工作区状态但要重置暂缓区(A/B/C文件与工作区状态我都不想要了)：

此时 --mixed 非常合适。

git reset --mixed [index]

因为 --hard 会参与工作区与暂缓区，所以不合适。

因为 --soft 不会参与工作区与暂缓区，所以不合适。

---

总结： 它们均有移动 HEAD 指针的能力，但是它们对于工作区与暂缓区的处理却是不同的。