文章参考廖老师的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
查看命令历史,以便确定要回到未来的哪个版本。