前言
前面了解过，每次提交都会产生新的id，master引用分支总是会指向最新的提交id，其实，引用也可以指向历史id，将当前版本指向历史id，这就是重置。
引用就像是一个游标，可上可下。git提供了reset命令来指向任意一个id。
reset
git reset命令就是用来重置的命令，利用这个命令可以回退到想要的版本，下面可以试验一下
先创建一个新文件，并提交
$ touch newfile
$ git add newfile
$ git commit -m "does master follow this new commit?"
[master 6a26023] does master follow this new commit?
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 newfile
$ ls
hellogit newfile查看master引用指向的id
$ cat .git/refs/heads/master
6a2602307968a2fa13efc3974ab4e0f4e7abf49a确实指向了新的提交id，查看一下日志
$ git log --oneline
6a26023 (HEAD -> master) does master follow this new commit?
6cffe14 2018.4.20 change1
5782fe2 third change
0789463 which version checked in?
ac01ff3 init hellogit file
现在想将版本重置到父提交
$ git reset --hard HEAD^
HEAD is now at 6cffe14 2018.4.20 change1再查看master引用
$ cat .git/refs/heads/master
6cffe145e4f83255fbdef7f68c4b0ed94acea8bc确实指向了父提交了，再看下日志
$ git log --oneline
6cffe14 (HEAD -> master) 2018.4.20 change1
5782fe2 third change
0789463 which version checked in?
ac01ff3 init hellogit filehead和master引用都指向了父提交，再看一下文件是否存在
$ ls
hellogit文件也删了
......
看了上面的日志，是完成了目的，回退到父提交了，但是，是不是有点太干净了，没有任何的回退记录，那如果是错误的回退怎么办，连日志都没了！！！这是一个危险的操作（特别是--hard参数，会破坏工作区未提交的改动），会彻底的丢弃历史，所以是不可能通过提交历史的办法来恢复，所以慎重！！！！
reflog
git作为一个这么x的版本控制工具，岂会不考虑错误重置的这种情况。reflog就是来挽救错误的reset。
在.git/logs目录下记录了分支的变更（必须是带有工作区的提供分支日志功能）。这是因为带有工作区的版本库都有以下设置
$ git config core.logallrefupdates
true查看一下master分支的日志文件
$ tail -5 .git/logs/refs/heads/master
ac01ff39a78fa388e1e628754fd55a76feb358d2 0789463b17be77ffe8da6fbc7e4b7777d065008c smxknife <2323937771@qq.com> 1522171550 +0800 commit: which version checked in?
0789463b17be77ffe8da6fbc7e4b7777d065008c 5782fe225003c2bc481d554ddeeab8fecd0dd19d smxknife <2323937771@qq.com> 1522171984 +0800 commit: third change
5782fe225003c2bc481d554ddeeab8fecd0dd19d 6cffe145e4f83255fbdef7f68c4b0ed94acea8bc smxknife <2323937771@qq.com> 1524190757 +0800 commit: 2018.4.20 change1
6cffe145e4f83255fbdef7f68c4b0ed94acea8bc 6a2602307968a2fa13efc3974ab4e0f4e7abf49a smxknife <2323937771@qq.com> 1524318936 +0800 commit: does master follow this new commit?
6a2602307968a2fa13efc3974ab4e0f4e7abf49a 6cffe145e4f83255fbdef7f68c4b0ed94acea8bc smxknife <2323937771@qq.com> 1524323213 +0800 reset: moving to HEAD^在这里可以找到最后的操作日志，最后一条，reset：moving to HEAD^，提交id由6a26变为6cff
除了直接查看文件外，还可以通过reflog命令来查看
$ git reflog show master | head -5
6cffe14 master@{0}: reset: moving to HEAD^
6a26023 master@{1}: commit: does master follow this new commit?
6cffe14 master@{2}: commit: 2018.4.20 change1
5782fe2 master@{3}: commit: third change
0789463 master@{4}: commit: which version checked in?可以看到同样的效果，只是对日志里面的信息进行精简和包装。在reflog命令中提供了一个方便易记的表达式：refname@{n}，上面输出的就是master@{0}。这个表达式的意思是refname之前第n次改变时的id值。那么将master切换之前的值，可以使用下面的命令
$ git reset --hard master@{1}
HEAD is now at 6a26023 does master follow this new commit?查看日志
$ git log --oneline
6a26023 (HEAD -> master) does master follow this new commit?
6cffe14 2018.4.20 change1
5782fe2 third change
0789463 which version checked in?
ac01ff3 init hellogit file查看引用
$ cat .git/refs/heads/master
6a2602307968a2fa13efc3974ab4e0f4e7abf49a查看工作区文件
$ ls
hellogit newfile用reflog命令查看日志
$ git reflog show master | head -5
6a26023 master@{0}: reset: moving to master@{1}
6cffe14 master@{1}: reset: moving to HEAD^
6a26023 master@{2}: commit: does master follow this new commit?
6cffe14 master@{3}: commit: 2018.4.20 change1
5782fe2 master@{4}: commit: third change深入了解git reset命令
$ echo "this is new" >> newfile
$ git status -s
M newfile
$ git diff
diff --git a/newfile b/newfile
index e69de29..fff92cf 100644
--- a/newfile
+++ b/newfile
@@ -0,0 +1 @@
+this is new
$ git add newfile
$ git status -s
M newfile
$ git diff
$ git reset HEAD
Unstaged changes after reset:
M newfile
$ git status -s
M newfile
$ git diff
diff --git a/newfile b/newfile
index e69de29..fff92cf 100644
--- a/newfile
+++ b/newfile
@@ -0,0 +1 @@
+this is new
从上面的操作来看，git reset HEAD 并没有改变工作区。改变的只有暂存区文件。将git add newfile 重置为add之前的状态。如果get reset HEAD^^ 就会发现引用也被改变，暂存区也被改变，只有工作区没有变化
--hard
使用hard模式会执行以下三个操作：
- 替换引用的指向。引用指向新的提交id
- 替换暂存区。替换后，暂存区的内容和引用指向目录树一致
- 提供工作区。替换后，工作区的内容变得和暂存区一致（引用、暂存区、工作区状态一致）
--soft
soft模式会执行一个操作：
- 更改引用的指向，不改变暂存区和工作区
--mixed
mixed模式同上面的git reset HEAD~n
- 将引用和暂存区回退到执行提交，工作区不变
关于内部类的详细文章可以参考目录 [smxknife's Java内部类]