与 rebase 一样，reset 只对当前分支和工作区，暂存区的数据有影响，对参数中指定的引用没有影响。即 (@f/table)git reset --hard dev 这句命令，影响的是 f/table 分支，对 dev 没有任何影响。
具体来看：
git reset --hard从参数名可以猜到，这个重置方式比较“强硬”，实际上就是，将当前分支，重置到与指定引用一样的状态，丢弃在这之后的提交，以及工作区和暂存区的提交。
未追踪的文件是不受影响的，PS：git clean 命令会清除掉未追踪的文件。
案例1
(@f/table)git reset --hard f/table~2 的含义？
当前在 f/table 分支，将其重置到 f/table~2 ，结果就是：丢弃掉 f/table 最新的两个提交。
案例2
将当前分支重置到远端最新 dev 的状态，怎么做？
(@f/table)git fetch
(@f/table)git reset --hard origin/dev
注意，这里需要先 fetch 一下远程仓库，更新 origin/dev 分支。
理解了 --hard 的含义，--soft 和 --mixed 就很好理解了，这两个参数，不会丢弃任何内容。
--soft 会将指定提交之后的提交内容，都放到 暂存区，同理，--mixed 会将指定提交之后的提交内容，以及暂存区中的内容，放到工作区。
所以，git reset --mixed HEAD (可以简写为 git reset)，实现的效果就是：将暂存区中的内容，回退到工作区。
git reset --hard HEAD (可以简写为 git reset --hard)，实现的效果就是：将工作区和暂存区中的全部内容。
案例1 将图中的 2 3 4合并为一个提交
案例2 移除误合并
reset 用于修改错误，通常会修改提交历史，
这在团队协作分支上是危险且不允许的（如很多仓库的 master 分支）。
这时可以使用 revert 命令。
revert 很好理解，就是新建一个提交，用于撤销之前的修改。
有个问题，revert 一个 merge 提交会怎么样？
如图，如果执行 (@f/table)git revert 6
会得到类似这样的提示：
这时，使用 -m 参数可以指定保留那边的提交，可选内容只有 1 和 2 （对于通常的两两合并的情况而言），
1 指代当前分支的那些提交，如果不是很确定，可以使用 git show 命令查看那个合并提交，在前的那个父节点为 1 。
留两个思考题：
1 如何在一切皆 commit 的语境下理解 git commit --amend
2 如何在一切皆 commit 的语境下理解 git stash