上一篇主要说的是，Git的基础部分，也就是代码的add操作和commit操作是主要说的点。
这一篇呢，主要说一下怎么把代码从版本库，暂存区中回退。
例子也用上一篇中的例子继续说。
1.git reset HEAD^^/HEAD~2
这个指令的意思是，让版本库，暂存区的内容回退2次。工作区不变。
那回退一次的操作就是git reset HEAD^/HEAD~1，这个规律不难看的出来吧。
OK，现在我们来试一下。
我现在给a.txt再执行两次add和commit操作。
然后我们看一下提交记录
可以看到啊，我们有a.txt的三次提交记录，现在我们给它进行回退操作。
可以看到我会退了两次之后，我们a.txt已经变成了红色的感叹号。
说明暂存区和版本库已经发生了变化，如果我们想验证一下可以用我上一篇说过的指令。
通过 这两个指令我们也看到了，暂存区和版本库的确发生了改变。
2.git reset --hard HEAD^/HEAD~1
这个指令的意思也是回退，加了–hard之后，会退的部分就把工作区也加上了。
也就是说这个回退是把工作区，暂存区，版本库三个区域都进行回退。
我们把a.txt提交一下之后试一下这个指令。
可以看到a.txt的内容也被回退了。
并且记住以下这个提示消息
现在我们再用git diff 指令查看一下
可以看到，三个区域已经同步了。说明暂存区和版本库中页被回退了。
3.git reset --hard + CommitID
刚才我们在进行回退操作时，成功后会给你一个提示（刚才我让记住的那个提示）
HEAD is now at …
这个就是版本记录的ID，也就是我们可以通过CommitID直接进行回退。
现在我们再用b.txt进行操作。
我们给b.txt进行三次add和commit操作。
然后我们git log 一下看看。
可以看到我有三条提交记录。
我在上一篇说过，这条黄色的记录中的一串，前八位就是这个记录的CommitID，现在我们有了它，我们就可以进行回退操作。
我们就拿第二次提交的记录的CommitID来进行回退（ID为6bec9199）
可以看到b.txt的工作区内容已经回退。
现在我们再用git diff 来看一下：
看的出来，三个区域已经没有差异，说明版本库和暂存区的内容都已经回退。
4.git revert HEAD
这个指令也是回退的意思，不过他和上面的区别在于，他不会修改已生成的版本记录，但会创建一个新的提交。
但是这个会发生冲突。
也就是说，虽然上一个指令进行了回退，但是它回退的同时也把版本记录给删除掉了，也就是你找不到之前的提交了，但是这个指令不会删除之前的提交记录，而是产生一条新的记录。
现在我们新建一个c.txt然后进行三次add和commit操作。
然后使用这个指令。
可以看到他给我报错了，还有黄色的提示，并且我的c.txt也变成了黄色的感叹号。
现在我打开c.txt看一下。
变成了这样是什么意思呢。
也就是和我们说要我们自己解决冲突问题。
我们要把分界线外的部分手动删除。
然后再进行add和commit操作。
这样这个指令才算彻底结束。
然后我们再log一下，其实通过这个过程我们也知道刚才的版本记录不会被删除。
看得到，之前的三条记录没有被删除，而且有一条新的提交记录。
然后我们也进行了回退操作。
这个指令给我的感觉就是手动自己回退…
5.git restore --worktree file
这个指令是只对工作区的文件进行回退。。。
我认为用处不是很大，和Ctrl+z没啥区别。。
例如我在c.txt中写东西，然后使用这个指令
然后就被回退了。。。。
6.git restore --staged file
这个指令是对暂存区的文件进行回退，我认为这个用处更小
我现在把c.txt提交一下，然后进行这个操作就可以对暂存区的文件进行回退。
但是谁没事只对暂存区的文件修改啊，那不是更没用吗。
OK，关于Git的回滚部分，也就说的差不多了！
