文章参考廖老师的Git教程
我们添加并提交了一个readme.txt文件，现在我们继续来修改这个文件，在文件的后面我添加一行。
然后运行命令 git status 来查看结果如何：
git status 命令可以让我们时刻掌握当前的状态，上面命令告诉我们，readme.txt被修改了，但是还没有准备提交的修改。虽然Git告诉我们readme.txt被修改了，如果我们不知道上次修改了readme.txt什么内容，可以通过 git diff 这个命令查看:
git diff 就是查看difference，显示的格式是Unix通用的diff格式，可以从图片看出，我在最后一行添加了一句话，绿色的那一行是我后面修改的。
知道了readme.txt做了什么修改后，将它提交到仓库就安心多了，提交修改和提交新文件是一样的两步，第一步: git add
在执行第二步: git commit 之前，我们可以运行 git status 查看当前仓库的状态:
git status 告诉我们，将要被提交的修改包括readme.txt，下一步就可以放心地提交:(-m 参数参考上一篇文章的解释)
提交后再使用git status命令查看仓库的当前状态:
Git告诉我们当前没有需要提交的修改，而且，工作目录是干净（working tree clean）的。
上面所有的内容就介绍了两个命令，git status命令查看工作区的状态，如果git status命令提示文件被修改，可以使用git diff查看修改内容。
版本回退
上面已经学会了修改文件，然后把修改提交到Git版本库，这里再修改一次来测试我的版本回退。
这里通过Git中的命令 git log 来查看修改的历史记录。该命令显示从最近到最远的提交日志，如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline只写 --onleline也可以，只会显示commit id 的前几个字符
这里看到的一大串的黄色字符是 commit id(提交的版本号)，和SVN不一样，Git的commit id不是1，2，3...递增的数字，而是一个SHA1计算出来的数字，用十六进制表示。
现在我需要把readme.txt回退到上一个版本，这里也就是 测试修改 那个版本，这里使用 git reset 命令: git reset --hard HEAD^
首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。
这里可以看到执行命令后再查看readme.txt中的内容变成了我第二次修改的数据。果然还原到上一个版本了（测试修改 版本）
这里用git log 再查看下现在的版本库状态:
可以看到最新的那个版本 从继续修改 变成了测试修改 ，好比你从21世纪坐时光穿梭机来到了19世纪，想再回去已经回不去了，肿么办？办法其实还是有的，只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个继续修改的commit id于是就可以指定回到未来的某个版本，这里的commit id(版本号)没有必要写全，前几位就可以，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。
查看teadme.txt的内容，又变成了原来最新的内容了。
Git版本的回退速度特别快，因为Git在内部有个指向当前版本的HEAD指针，Git仅仅是把 HEAD 从 继续修改:
改为指向 测试修改:
然后顺便把工作区的文件更新了，所有你让HEAD指向哪个版本号，你就把当前版本定位在哪？
现在，你回退到了某个版本，关闭Git，想恢复到新版本怎么办？找不到新版本的commit id怎么办？
在Git中，总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到 测试修改 版本时，再想恢复到 继续修改，就必须找到 继续修改 的commit id。Git提供了一个命令git reflog用来记录你的每一次命令：
于是你就知道了 继续修改 的commit id是多少了，执行git reset就可以回到 继续修改 了
关于版本回退的小总结
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。