4.时光穿梭机
我们已经成功的提交了一个123.txt,我们需要继续工作,然后继续修改123.txt文件,改成如下内容:
现在运行git status命令查看结果:
git status
命令可以让我们时刻掌握仓库当前的状态,上面的命令输出告诉我们,123.txt
被修改过了,但还没有准备提交的修改。
具体查看修改了什么内容就使用git diff <file>命令来查看:
知道对123.txt修改了后,我们再把它提交到仓库:
提交后,我们再用git status查看状态:
1)版本回退
我们再次修改内容,:
然后再提交 :
像这样,你不断对文件进行修改,然后不断提交修改到版本库里,就好比玩RPG游戏时,每通过一关就会自动把游戏状态存盘,如果某一关没过去,你还可以选择读取前一关的状态。有些时候,在打Boss之前,你会手动存盘,以便万一打Boss失败了,可以从最近的地方重新开始。Git也是一样,每当你觉得文件修改到一定程度的时候,就可以“保存一个快照”,这个快照在Git中被称为commit
。一旦你把文件改乱了,或者误删了文件,还可以从最近的一个commit
恢复,然后继续工作,而不是把几个月的工作成果全部丢失。
我们可以使用git log来查看历史记录:
git log
命令显示从最近到最远的提交日志,我们可以看到3次提交 。
如果嫌输出信息太多,看得眼花缭乱的,可以试试加上--pretty=oneline
参数:
如上一串数字,是commit id
(版本号),和SVN不一样,Git的commit id
不是1,2,3……递增的数字,而是一个SHA1计算出来的一个非常大的数字,用十六进制表示,而且你看到的commit id
和我的肯定不一样,以你自己的为准。为什么commit id
需要用这么一大串数字表示呢?因为Git是分布式的版本控制系统,后面我们还要研究多人在同一个版本库里工作,如果大家都用1,2,3……作为版本号,那肯定就冲突了。
现在我们启动时光穿梭机,准备把123.txt回退到上一个版本呢,也就是”修改了文件“的版本。
首先,Git必须知道当前版本是哪个版本,在Git中,用HEAD
表示当前版本,也就是c7d11...开头的版本,上一个版本就是HEAD^
,上上一个版本就是HEAD^^
,当然往上100个版本写100个^
比较容易数不过来,所以写成HEAD~100
。
现在,我们把当前版本“我再次修改了内容”回退到上一个版本“我修改了内容”,就可以使用git reset命令:
看看123.txt的内容是不是“修改了文件”的版本:
我们再用git log命令看看,已经找不到“我再次修改了内容”的版本了:
如果你再想回到最新的版本“再次修改了内容”的版本,可以使用commit id(版本号没必要写全,输入前面几个数字就行了)来恢复:
如果你,回退了某个版本,不记得最新版本的commit id,可以使用git reflog命令来记录你每一次命令:
这样你可以找到cfd11e1的版本号,可以回到最新版本。
2)撤销修改
1)我们再次修改了123.txt文件时,你准备提交时候,发现修改错误了,你可以手动恢复。
我们可使用git status来查看:
git提示你可以使用git checkout -- <file> 来丢弃工作区的改动:
命令git checkout -- 123.txt
意思就是,把123.txt
文件在工作区的修改全部撤销,这里有两种情况:
一种是123.txt
自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
一种是123.txt
已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
总之,就是让这个文件回到最近一次git commit
或git add
时的状态。
2)当我们通过git add命令添加到暂存区的时候,没有commit之前。你可以git status查看:
git提示你可以使用git reset HEAD <file>命令来撤出暂存区:
git reset
命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD
时,表示最新的版本。
再用git status
查看一下,现在暂存区是干净的,工作区有修改:
再用git checkout -- <file> 来丢弃工作区的改动。
3)删除文件
在Git中,删除也是一个修改操作,我们实战一下,先添加一个新文件456.txt到Git并且提交:
一般情况下,你可以直接使用rm命令删除:
这时候git知道你删除了文件,工作区和版本库就不一样,git status命令告诉你哪些文件被删除了:
现在你有两种选择,一是确定要从版本库中删除该文件,就用命令git rm删掉,并且git commit:
另一种情况是删错了,因为版本库里还有呢,所以很轻松把误删除的文件恢复: