git之reset图解

https://blog.csdn.net/longintchar/article/details/81843048 

1、三棵树。

此时如果我们运行 git status，会发现没有任何改动，因为现在三棵树完全相同。

修改文件

现在我们想要对文件进行修改然后提交它。我们将会经历同样的过程；首先在工作目录中修改文件。 我们称其为该文件的 v2 版本，并将它标记为红色。

如果现在运行 git status，我们会看到文件显示在 “Changes not staged for commit” 下面，并被标记为红色，因为该条目在索引与工作目录之间存在不同。 接着我们运行 git add 来将它暂存到索引中。

再次添加到索引

此时，由于 Index 和 HEAD 不同，若运行 git status 的话就会看到 “Changes to be committed” 下的该文件变为绿色 ——也就是说，现在预期的下一次提交与上一次提交不同。 最后，我们运行 git commit 来完成提交。

再次提交

现在运行 git status 会没有输出，因为三棵树又变得相同了。

切换分支或克隆的过程也类似。 当检出一个分支时，它会修改 HEAD 指向新的分支引用，将索引填充为该次提交的快照，然后将索引的内容复制到工作目录 中。

reset 的作用
在以下情景中观察 reset 命令会更有意义。

为了演示这些例子，假设我们再次修改了 file.txt 文件并第三次提交它。 现在的历史看起来是这样的：

第 1 步：移动 HEAD
reset 做的第一件事是移动 HEAD 的指向。 这与改变 HEAD 自身不同（checkout 所做的）；reset 移动 HEAD 指向的分支。 这意味着如果 HEAD 设置为 master 分支（例如，你正在 master 分支上），运行 git reset 9e5e6a4 将会使 master 指向 9e5e6a4。

结合上图，我们理解一下发生的事情：它本质上是撤销了上一次 git commit 命令。 当你在运行 git commit 时，Git 会创建一个新的提交，并移动 HEAD 所指向的分支来使其指向该提交。 当你将它 reset 回 HEAD~（HEAD 的父结点）时，其实就是把该分支移回原来的位置，而不会改变索引和工作目录。

第 2 步：更新索引（–mixed）

接下来，reset 会用 HEAD 指向的当前快照的内容来更新索引。

如果指定 –mixed 选项，reset 将会在这里停止。 这也是默认行为，即如果没有指定任何选项（在本例中是 git reset HEAD~），reset 将会在这里停止。

现在再看一眼上图，理解一下发生的事情：它依然会撤销一上次提交，但还会取消所有暂存。 于是，我们回滚到了所有 git add 和 git commit 的命令执行之前。

第 3 步：更新工作目录（–hard）
如果使用 –hard 选项，reset 要做的的第三件事情就是让工作目录看起来像索引。

现在让我们回想一下刚才发生的事情：你撤销了最后的提交（git commit ）、git add 和工作目录中的所有工作。

必须注意，–hard 标记是 reset 命令唯一的危险用法，它也是 Git 会真正地销毁数据的仅有的几个操作之一。其他任何形式的 reset 调用都可以轻松撤消，但是 –hard 选项不能，因为它强制覆盖了工作目录中的文件。

总结

reset 命令会以特定的顺序重写这三棵树，在你指定以下选项时停止：

1. 移动 HEAD 指向的分支 （若指定了 --soft，则到此停止）；
2. 重置 index 以便和 HEAD 相匹配 （若未指定 --hard，则到此停止）；
3. 使工作目录看起来像索引