Git-时光机穿梭

发表于 | 分类于

Git 时光机穿梭

我们已经可以将文件添加到git仓库了，下面我们试着修改这个文本文件，看看会有什么结果:

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

修改完成后，保存，然后运行 git status 看看有什么结果:

1
2
3
4
5
6
7
8
9
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   readme.txt
no changes added to commit (use "git add" and/or "git commit -a")

这样，返回的信息就会告诉我们，现在有文件被修改了，但是还没有被提交（changes not staged for commit）。
虽然git status可以告诉我们当前仓库的状况，但是并不能清楚的告诉我们修改了哪些地方。这时候，我们就需要用到git diff命令:

1
2
3
4
5
6
7
8
9
$ git diff readme.txt
diff --git a/readme.txt b/readme.txt
index 23bc09e..9247db6 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@
-Git is version control system.
+Git is a distributed version control system.
 Git is free software.

现在，我们知道了readme.txt中只修改了一行内容。所以我们就可以安心的提交更改了:

1
$ git add readme.txt

这时候，我们再来看一下git仓库的状态，使用git status命令:

1
2
3
4
5
6
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   readme.txt

这时，系统告诉我们，将要被提交的修改包含了readme.txt文件。
现在我们就提交这次修改，使用git commit命令:

1
2
3
$ git commit -m 'add distributed'
[master 3b15474] add distributed
 1 file changed, 1 insertion(+), 1 deletion(-)

提交完成后，我们再使用git status来查看一下仓库的状态:

1
2
3
$ git status
On branch master
nothing to commit, working tree clean

这时，返回的信息告诉我们，没有需要提交的修改，而且工作目录是干净的。

版本回退

现在我们已经学会了如何修改文件并且将修改提交到git仓库了，下面再联系一次:

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

然后提交修改:

1
2
3
4
$ git add readme.txt
$ git commit -m 'append GPL'
[master 9b51472] append GPL
 1 file changed, 1 insertion(+), 1 deletion(-)

像这样，你不断对文件进行修改，然后不断提交修改到版本库里，就好比玩RPG游戏时，每通过一关就会自动把游戏状态存盘，如果某一关没过去，你还可以选择读取前一关的状态。有些时候，在打Boss之前，你会手动存盘，以便万一打Boss失败了，可以从最近的地方重新开始。Git也是一样，每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在Git中被称为commit。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失。

好，现在我们回顾一下我们一共有多少个版本了:
版本1: add readme file

1
2
Git is a version control system.
Git is free software.

版本2: add distributed

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

版本3: append GPL

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

在git中，我们可以使用git log命令来查看历史记录，它可以告诉我们每次都修改了些什么:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ git log
commit 9b5147211afee2c3b233d2f74de5f4cec710977b (HEAD -> master)
Author: louis <louis@promote.cache-dns.local>
Date:   Mon Jan 29 16:26:38 2018 +0800
    append GPL
commit 3b1547438f09df37716d770a9919fce34405994f
Author: louis <louis@promote.cache-dns.local>
Date:   Mon Jan 29 16:21:32 2018 +0800
    add distributed
commit 7b235af1f06c6952dd4cd41eea8c77bb02be5dce
Author: louis <louis@promote.cache-dns.local>
Date:   Mon Jan 29 14:55:59 2018 +0800
    add readme file

如果觉得输出的信息太多了，可以试着使用git log --pretty=online，这样，就能看到最精简的信息了。

这里的commit 7b235af1f06c6952dd4cd41eea8c77bb02be5dce就是版本号了，和SVN不一样，git的版本号不是1，2，3，4这样递增的数字，而是一个SHA1计算出来的非常大的数字，用16进制表示。为什么commit id需要用这么一大串数字表示呢？因为Git是分布式的版本控制系统，后面我们还要研究多人在同一个版本库里工作，如果大家都用1，2，3，4作为版本号，那肯定就冲突了。

好了，现在我们知道了这些版本的历史记录之后，就可以启动时光穿梭机了。我们准备把readme.txt回退到上一个版本，即”add distributed”的那个版本，需要怎么做呢？
首先，必须知道当前版本是哪个版本，在git中，使用HEAD表示当前的版本，上一个版本就是HEAD^，上上个版本就是HEAD^^，但是如果是上100个版本呢？我们可以写成HEAD~100。
现在我们要把当前版本”append GPL”回退到上一个版本”add distributed”，我们需要使用到git reset命令:

1
2
$ git reset --hard HEAD^
HEAD is now at 3b15474 add distributed

--hard的含义，后续会讲到，先来看看readme.txt是否回到了add distributed版本:

1
2
3
$ cat readme.txt
Git is a distributed version control system.
Git is free software.

可以发现，现在我们确实回到了add distributed那个版本，我们还可以继续回到上一个版本，不过我们先停一下，使用git log查看一下版本记录:

1
2
3
4
5
6
7
8
9
10
11
12
$ git log
commit 3b1547438f09df37716d770a9919fce34405994f (HEAD -> master)
Author: louis <louis@promote.cache-dns.local>
Date:   Mon Jan 29 16:21:32 2018 +0800
    add distributed
commit 7b235af1f06c6952dd4cd41eea8c77bb02be5dce
Author: louis <louis@promote.cache-dns.local>
Date:   Mon Jan 29 14:55:59 2018 +0800
    add readme file

什么？！我们的append GPL的版本怎么不见了呢？好比你从21世纪坐时光穿梭机来到了19世纪，想再回去已经回不去了，肿么办？
办法其实还是有的，只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个append GPL的commit id是9b51472…，于是就可以指定回到未来的某个版本：

1
2
$ git reset --hard 9b51472
HEAD is now at 9b51472 append GPL

版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。

再小心翼翼地看看readme.txt的内容:

1
2
3
$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.

果然，我胡汉三又回来了。

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL:
append GPL
改为指向add distributed:
add distributed
然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。

现在，你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？

在Git中，总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到add distributed版本时，再想恢复到append GPL，就必须找到append GPL的commit id。Git提供了一个命令git reflog用来记录你的每一次命令：

1
2
3
4
5
6
$ git reflog
9b51472 (HEAD -> master) HEAD@{0}: reset: moving to 9b51472
3b15474 HEAD@{1}: reset: moving to HEAD^
9b51472 (HEAD -> master) HEAD@{2}: commit: append GPL
3b15474 HEAD@{3}: commit: add distributed
7b235af HEAD@{4}: commit (initial): add readme file

从返回的信息可以看出来，append GPL的commit id为9b51472。这样，我们就又可以回到未来啦！

工作区和暂存区

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

先来看名词解释。

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

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

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

前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：

第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；

第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

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

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

俗话说，实践出真知。现在，我们再练习一遍，先对readme.txt做个修改，比如加上一行内容:

1
2
3
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.

然后，在工作区新增一个LICENSE文件:

1
2
$ touch LICENSE
$ nano LICENSE

现在，我们用git status查看一下仓库的状态:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   readme.txt
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	LICENSE
no changes added to commit (use "git add" and/or "git commit -a")

返回的信息清楚的告诉了我们，readme.txt被修改了，而LICENSE是第一次出现，所以状态是Untracked。

现在，使用两次git add，把两个文件都添加后，再使用git status查看一下:

1
2
3
4
5
6
7
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	new file:   LICENSE
	modified:   readme.txt

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

1
2
3
4
$ git commit -m "understand how stage works"
[master 2e3b6fb] understand how stage works
 2 files changed, 2 insertions(+)
 create mode 100644 LICENSE

一旦提交成功后，这时你的工作区就是干净的了:

1
2
3
$ git status
On branch master
nothing to commit, working tree clean

现在，版本库就变成了这样:
版本库

管理修改

现在，我们已经掌握了暂存区的概念。接下来，我们讨论一下，为什么Git比其他版本控制系统设计的优秀，因为Git跟踪并管理的是修改，而非文件。
那什么是修改呢？比如你新增了一行，这就是一个修改；删除了一行，也是一个修改；更改了某些字符，也是一个修改；删了一些又加了一些，也是一个修改；甚至创建一个新文件，也算一个修改。
为什么说Git管理的是修改，而不是文件呢？我们还是做实验。第一步，对readme.txt做一个修改，比如加一行内容:

1
2
3
4
5
$ cat readme.text
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes.

然后，添加到暂存区:

1
2
3
4
5
6
7
$ git add readme.txt
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   readme.txt

然后，再次修改readme.txt:

1
2
3
4
5
$ cat readme.txt 
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.

提交:

1
2
3
$ git commit -m 'git tracks changes'
[master 43daa3e] git tracks changes
 1 file changed, 1 insertion(+)

提交后，再看看状态:

1
2
3
4
5
6
7
8
9
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   readme.txt
no changes added to commit (use "git add" and/or "git commit -a")

为什么这里第二次的修改没有被提交呢？
我们来回顾一下整个操作过程:
第一次修改 -> git add -> 第二次修改 -> git commit
我们前面讲了，Git管理的是修改，当你使用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。
提交后，用git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别:

1
2
3
4
5
6
7
8
9
10
11
$ git diff HEAD -- readme.txt
diff --git a/readme.txt b/readme.txt
index 76d770f..a9c5755 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,4 +1,4 @@
 Git is a distributed version control system.
 Git is free software distributed under the GPL.
 Git has a mutable index called stage.
-Git tracks changes.
+Git tracks changes of files.

可见，第二次修改确实没有被提交。那怎么才能提交第二次的修改呢？只有继续使用git add将修改提交到暂存区，然后再使用git commit将暂存区的修改提交。现在可以了解到，每一次修改，如果不add到暂存区，那就不会加入到commit中。

撤销修改

自然，你是不会犯错的。不过现在是凌晨两点，你正在赶一份工作报告，你在readme.txt中添加了一行:

1
2
3
4
5
6
$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My stupid boss still prefers SVN.

在你准备提交前，一杯咖啡起了作用，你猛然发现了“stupid boss”可能会让你丢掉这个月的奖金！

既然错误发现得很及时，就可以很容易地纠正它。你可以删掉最后一行，手动把文件恢复到上一个版本的状态。如果用git status查看一下:

1
2
3
4
5
6
7
8
9
$ git status
 On branch master
 Changes not staged for commit:
   (use "git add <file>..." to update what will be committed)
   (use "git checkout -- <file>..." to discard changes in working directory)
       modified:   readme.txt
no changes added to commit (use "git add" and/or "git commit -a")

从返回的信息可以发现，你可以使用git checkout -- readme.txt来丢弃工作区的修改:

1
$ git checkout -- readme.txt

命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

总之，就是让这个文件回到最近一次git commit或git add时的状态。

现在，看看readme.txt的文件内容：

1
2
3
4
5
$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.

文件内容果然复原了。

git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。

现在假定是凌晨3点，你不但写了一些胡话，还git add到暂存区了：

1
2
3
4
5
6
7
8
$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My stupid boss still prefers SVN.
$ git add readme.txt

这时，使用git status查看一下当前的状态:

1
2
3
4
5
6
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   readme.txt

Git同样告诉我们，用命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区：

1
2
3
$ git reset HEAD readme.txt
Unstaged changes after reset:
M       readme.txt

git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。

再用git status查看一下，现在暂存区是干净的，工作区有修改:

1
2
3
4
5
6
7
8
9
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	modified:   readme.txt
no changes added to commit (use "git add" and/or "git commit -a")

还记得如何撤销工作区的修改吗？

1
2
3
4
5
$ git checkout -- readme.txt
$ git status
 On branch master
nothing to commit (working directory clean)

现在，假设你不但改错了东西，还从暂存区提交到了版本库，怎么办呢？还记得版本回退一节吗？可以回退到上一个版本。不过，这是有条件的，就是你还没有把自己的本地版本库推送到远程。还记得Git是分布式版本控制系统吗？我们后面会讲到远程版本库，一旦你把“stupid boss”提交推送到远程版本库，你就真的惨了……

场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。

场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

删除文件

在Git中，删除也是一个修改操作，我们实战一下，先添加一个新文件test.txt到Git并且提交：

1
2
3
4
5
$ git add test.txt
$ git commit -m 'add test.txt'
[master e432478] add test.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test.txt

一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用rm命令删了：

1
$ rm test.txt

这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：

1
2
3
4
5
6
7
8
9
$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
	deleted:    test.txt
no changes added to commit (use "git add" and/or "git commit -a")

现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：

1
2
3
4
5
6
$ git rm test.txt
rm 'test.txt'
$ git commit -m 'remove test.txt'
[master cdaffb3] remove test.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 test.txt

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

另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

1
$ git checkout -- test.txt

git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。