【三】版本之间穿梭切换

版本之间穿梭切换

1. 版本回退
2. 回退版本
3. 工作区和暂存区
4. 管理修改
5. 撤销修改
6. 删除文件

再穿梭前，我们先修改readme.txt文件，修改为：

Git is a distributed version control system.
Git is free software.

运行git status命令看看结果：

git status命令可以让我们时刻掌握仓库的当前状态，例如上面的信息告诉我们readme.txt文件被修改了，还没有add所以不能commit。

如果不知道或忘记了修改了什么，可以使用git diff查看修改的具体内容(diff就是difference的缩写)：

红色文字前面有个减号-的就是删除的，绿色的前面有个加号+的就是新增的，以上信息告诉我们第一行新增了一个单词distributed。

知道了修改了什么就可以放心提交了，提交还是两步骤，第一步先git add，然后使用git status查看下状态：

这里信息告诉我们将要提交的修改包括readme.txt文件，然后第二步就可以提交了：

提交完成后，再使用git status查看仓库的当前状态：

上面信息说明没有需要提交的修改，而且工作目录是干净的。

1. 版本回退

先再来练习下，再修改一个版本，修改文件为：

Git is a distributed version control system.
Git is free software distributed under the GPL.

然后提交：

现在已经有3个版本的提交记录，使用git log查看：

git log命令显示从最近到最远的提交日志，我们可以看到3次提交，最近的一次是append GPL，上一次是add distributed，最早的一次是add a readme file。

如果嫌信息太多，可以加上--pretty=oneline就可以：

上面显示的一大串的字符是commit id（版本号），这是SHA1计算出来的一个非常大的数字，用十六进制表示，每个人的不一样，以自己的为准。

为什么commit id需要一大串字符表示呢？因为Git是分布式的版本控制系统，避免大家版本号冲突。

2. 回退版本

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交cc1510...（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

现在，我们要把当前版本append GPL回退到上一个版本add distributed，就可以使用git reset命令：

这里的HEAD^加引号是因为windows系统会把^当作换行符，不加引号会显示“more?”，如果你看到了不要奇怪哦。

先来看看文件还原了没有：

果然还原了。

再用git log看看现在版本库的状态：

额。。。最新的append GPL版本不见了！那怎么回到最新的版本呢？如果你没有清命令行记录还是可以找到commit id的，如果清了咋办呢？
还是有办法的，Git提供了一个命令git reflog用来记录你的每一次命令：

终于看到了append GPL的commit id是cc1510e，所以可以回去了：

commit id可以不用写全，前几位就可以了，只要能唯一代表就可以。

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL：

改为指向add distributed：

然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。

3. 工作区和暂存区

Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。

工作区（Working Directory）
就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区：

版本库（Repository）
工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。

你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

例如：我们再修改下readme.txt，然后再加一个LICENSE文件
使用git status查看下状态：

可以看到readme.txt是Changes not staged for commit（没有添加到暂存区，不能提交），而LICENSE是Untracked files（新文件没有被跟踪），使用git add后再看下状态：

现在，暂存区的状态就变成这样了：

所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。

现在版本库变成了这样，暂存区就没有任何内容了：

4. 管理修改

为什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。
修改：新增一行，修改字符，删除一行/字符，创建文件。。。

例如：

对readme.txt加一行
git add添加暂存
再修改readme.txt刚才加的一行
git commit提交到分支
git status查看状态

额。。。第二次修改没有被提交？为什么呢？

回顾操作：第一次修改 -> git add -> 第二次修改 -> git commit
因为第二次修改没有加到缓存区，而git commit只提交缓存区的修改到当前分支，所以只提交了第一次的修改。

使用git diff查看下：

可见第二次确实没有修改，我们可以继续git add再git commit，也可以和后面修改的文件一起add再一起commit。

5. 撤销修改

如果不小心修改错了文件，怎么撤回呢？这里有两种情况：

修改后还没有add到暂存区
已经add到暂存区了，又做了修改

先来看情况1（未add到暂存区）：

git提示我们git restore可以丢弃工作区的修改，执行后工作区的文件被还原了。

情况2（已add到暂存区）：
可以先用git restore --staged将文件从暂存区退回到工作区：

然后再使用git restore丢弃工作区的修改：

然后再看下状态，是clean状态的：

如果已经提交到分支了，那就直接回退版本就行了。

6. 删除文件

先添加一个文件test.txt，并提交：

此时删除文件：

然后这里有两个选择，一是误删了需要恢复，二是真的需要删除：

恢复删除的文件

此时文件又回来了，工作区和版本库相同了。
确认删除
使用git rm删除文件提交到暂存区，然后再git commit提交到当前分支：

现在文件就从版本库删除了。