版本回退
之前我们也提到过，Git能够管理文件的历史版本，这也是版本控制器重要的能力。如果有一天你发现之前的工作出现了很大问题，需要在某个特定的历史版本重新开始，这个时候就需要版本回退功能了。
执行 git reset 命令用于回退版本，可以指定退回某一次提交的版本。要解释一下 "回退" 本质是要将版本库中的内容进行回退，工作区或暂存区是否回退由命令参数决定：
git reset 命令语法格式： git reset [--soft | --mixed | --hard] [HEAD]
--soft 参数对于工作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。
--mixed 为默认选项，使用时可以不用带该参数。
该参数将暂存区的内容退回为指定提交版本内容，工作区文件保持不变。
--hard 参数将暂存区与工作区都退回到指定版本。
切记工作区有未提交的代码时不要用这个命令，因为工作区会回滚，你没有提交的代码就再也找不回了，所以使用该参数前一定要慎重。
HEAD说明：
可直接写成 commit id，表示指定退回的版本
◦ HEAD 表示当前版本
◦ HEAD^ 上一个版本
◦ HEAD^^ 上上一个版本
◦ 以此类推...
可以使用〜数字表示：
◦ HEAD~0 表示当前版本
◦ HEAD~1 上一个版本
◦ HEAD~2 上上一个版本
◦ 以此类推...测试回退功能：
回退到version2，重新基于version2开始编写。由于我们在这里希望的是将工作区的内容也回退到version2版本，所以需要用到--hard参数：
如果我后悔了，想再回到version3怎么办？我们可以继续使用git reset命令，回退到version3版本，但我们必须要拿到version3的commit id去指定回退的版本。
但我们看到了git log并不能打印出version3的commit id，运气好的话我们可以从终端上去找找之前的记录，运气不好的话commit id已经被我们搞丢了。
Git还提供了一个git reflog命令能补救一下，该命令用来记录本地的每一次命令。
Git的版本回退速度非常快，因为Git在内部有个指向当前分支（此处是master）的HEAD指针，refs/heads/master文件里保存当前master分支的最新commit id。当我们在回退版本的时候，Git仅仅是给refs/heads/master中存储一个特定的version，可以简单理解成如下示意图：
撤销修改
我们在⼯作区写了很⻓时间代码，想恢复到
上⼀个版本：
情况一：工作区的代码，还没有add
我们可以使用 git checkout -- file 命令让工作区的文件回到最近一次 add 或 commit 时的状态。要注意 git checkout -- file 命令中的 -- 很重要，切记不要省略，一旦省略，该命令就变为其他意思了。
情况二：已经add，但还没commit
git reset 回退命令如果使⽤--mixed 参数，可以将暂存区的内容退回为指定的版本内容，但⼯作区⽂件保持不变。那我们就可以回退下暂存区的内容了。
情况三：已经add，并且也commit了
可以 git reset --hard HEAD^ 回退到上⼀个版本。不过，这是有条件的，就是你还没有把⾃⼰的本地版本库推送到远程。
删除文件
在Git中，删除也是⼀个修改操作。如果要删除 f3⽂件，怎么搞呢？如果你这样做了:
但这样直接删除是没有⽤的，git status 命令会⽴刻告诉你哪些⽂件被删除了：
此时，工作区和版本库就不一致了，要删文件，目前除了要删工作区的文件，还要清除版本库的文件。
走到这里，一般有两种可能：
1.不小心删错了
2.确实要从版本库中删除文件第一种误删操作：需要用git进行恢复
对于第一种情况，很明显是没有删完，我们只删除了工作区的文件。这时就需要使用git rm 将文件从暂存区和工作区中删除，并且commit ：
现在，⽂件就从版本库中被删除了。
注意：
git rm f3 做了两件事：
1.从工作区删除 f3 文件
- 自动把"删除 f3"这件事加入暂存区