阅读《Pro Git》有感

个人理解，git是服务于“文本文件”的，准确地说，是服务于程序代码那种文本文件的。所以git本自然的以 行 作为其最小粒度。所以后面在merge等处理冲突（或者说合并多个流）的时候，git都是以行为单位进行匹配。这样做比目前较为通用的云同步在粒度上稍微细了一点，因为后者主要是面向二进制文件的，而二进制文件，是一变百变的。 举个例子，如果有需求对docx之类的文档进行版本控制，可能就没有merge一说，但是对txt或者基于xml组织的odt文档，这种基于行的版本控制或许就是可行的了。

另一个问题：什么是版本控制？我理解的版本控制是历史和多人合作。

*历史*是指：通过一个个的离散的时间节点来形成一张有向无环图，该图反应了一个软件（或者说，一团数据）随着变量时间的演化过程。

*多人合作*是指：上述有向无环图的构成，每一个节点的创建者未必是同一个人。当然，通过权限，某些汇聚节点（入度大于出度）的创建或许需要控制在管理员手里。

我想，提供了一张完整的有向无环图的创建和维护方法，应该就是git的核心功能吧。该图不仅仅是说我可以知道哪两个节点之间发生了何种提交（也就是*边*），更是说：/git 可以提供整张图里每个节点的完整信息。/

那么，难道过去的VCS（version control system）不是这么干的吗？差不多，实现上稍微有一些不同。（但是，谈论过去的VCS什么样子其实没有太大的意义。我会用他们吗？）过去的VCS主要是以文件为基本单位，如果某一个版本，对文件目录中的某些文件进行了修改，那么这个版本仅仅会记录那些发生修改的文件的修改之处，所以本质上相当于是渐进式的一条长河，不太有利于处理分支（不是不行，而是不高效）。

git则有些不同。git不以文件为单位，而以版本为单位，版本就是图中的点。当然，这并不是说每一个点都是独立存在的，我认为git还是以文件、行或者目录为单位，采用指针进行了高效存储的。

上述文字阐述了git的主要功用。下面看一看基于这种作用，常见的git的使用场景是什么，以及在该场景之下，如何对项目系统进行基本的处理。

从物理上而言，git一般包含以下两类物理地址：若干个本地终端；若干个云终端。对不对？ 所谓的多人协作，最直白的一种方案是：将若干个本地终端推送到一个云终端上去合并。 当然后面会详细介绍详细的工作流。 基于以上认识，git本质上是在上述vcs的有向无环图的基础上，还考虑了空间位置。换句话说：每个物理位置上，其实都会有依照时间变化的一张图。这张图其实是有“目的论”味道的，他们都大概率会进化到几个最终节点（出度为0的节点），这些=最终节点=会被移动到象征整个项目系统官方物理位置的地方，作为一个新的分支被合并。上述说法很含糊，后面会在介绍工作流时举例说明。现在还是把核心放在新增的维度——“空间”上。

对于物理上的空间（本地和远程），git其实也做了一些简单的区分。但是为了更加成体系地阅读，应该将本地地址进行进一步的细化，一般可以额外规划出来下面的区域：git法外之地，暂时存储地域，本地提交地域。加上远程地域，一共有四个：

1. git法外之地：也就是还没有接受git管辖的区域。比如，在一个文件夹之下，我新建了一个文件，这个文件就是在git法外之地的，因为git不知道有它(untracked)；
2. 发生修改的文件区域（unstaged）：这里的文件之前被提交过，但是又发生了更改。同时，更改还没有被暂存。
3. 暂时存储地域（staged）：顾名思义，这个地方所存储的文件，其变动和信息已经被正式捕获了，但是，这个地方还不能算是本地有向无环图中的一个点，所以才叫“暂存”。这个地方的文件一般包含两种情况：
   1. 之前在法外之地，没有被tracked的文件，被加入了git中。相当于是新加入的文件；
   2. 之前已经被归档到仓库里了，然后又进行了更改的文件。相当于是之前的文件发生了更改。
4. 归档好的仓库（repository）: 顾名思义，这里放着的就是正式决定存入仓库的东西（文件）。所谓的仓库，可以理解成git为该项目系统构建的一个档案袋。当一堆文件被加入到仓库里，那么一个新的“版本”就会出现，也就是有向无环图中的一个新的节点，就被创建出来的。与暂存区域不同，这里的数据是可回溯的。换句话说，当文件A被放入了归档好的仓库里之后，我们继续修改A，然后再把它放入仓库里，此时之前的文件A的状态，还是可以捕获的。这是版本控制的一大特点。
5. 远程的仓库。如果对于单人使用，远程仓库的意义或许仅仅是云备份罢了。过会再去详细介绍它。

在了解了上述几个储物间之后，一个值得考虑的问题是：暂时存储地域是不是多余的？你看，我切换图中的版本节点，暂存的数据还是会消失。如果我要想让他们不消失，就必须放到仓库里。那么我为什么中间要加入一个暂时存储的位子呢？这个问题先搁置一下，后面会介绍。让我们用审视古董的角度先接受它，然后暂时先看看在几个区域之间移动的几个基础操作。 注意：上述操作的前缀都是git。

1. add 将法外之地的文件添加到暂存区；
2. add 将被修改（modified）的文件添加到暂存区；
3. commit 将暂存区的文件放到仓库里，在当前节点的基础上，形成一个新的version节点。并使得上一个版本变成只读模式（是这个样子吗？）。
4. push 将若干个本地的commit，传递到远程的服务器的某个分支上。比如=git push origin master=，是说在origin这个名字的服务器上有一个分支叫做master，我把本地仓库和这个orgin下的master进行对齐。
5. rm 删除暂存区域中的某文件。
6. rm –cached 将从法外之地移入暂存区的文件，再变为untracked的状态，但不删除文件。
7. commit –amend 用于重新提供提交信息。取消上一次的提交信息，并输入新的。
8. reset HEAD 把处于暂存区的、是modified过的文件，改为unstage状态。
9. checkout – 把unstaged状态下的文件，也就是一个之前被commit过，但是修改了还没有commit的文件，还原回上一次commit时的状态。

值得注意的是，我在这里罗列一下他们，就仅仅是简单罗列一下。这些是不需要记忆的，因为用的熟了很多常用的就记住了，不常用的也没必要记录。再说，目前基本上是个IDE都会提供git工具，命令行就更不是必要的了。本文也是如此，理解外部原理就完全足够使用git的了。

下面还需要再看看本地仓库怎么跟远程的仓库建立关系。这一部分其实在branch之类的操作说完了之后才好讲解，因为这一过程是属于version-level而不是file-level的。

简单的跟远程相关的命令都包括git remote。如：

• git clone +url以完整拷贝一个仓库到本地；
• git remote，查看已有的远程仓库
• git remote add [remoteName] [URL] 以添加一个新的远程仓库链接（此时没有新增任何的文件数据）
• git fetch [remotename] 将该远程仓库下的所有东西作为新的若干个分支下载到本地

还有其他一些未介绍的命令：

• git remote show 展示一个remotename的信息
• git remote rename 重命名

下面就来看一看，version-level的一些工作。

之前提及过，版本控制过程，本质上可以理解为一张有向无环图。那么两个操作是VCS中最重要的：建图，和看图。 关于建图，其实就是迭代“建立节点，并提供连接”这个过程。

特殊地，git的VCS其实每个节点最多只会有两个上游节点，最多也只会有两个下游节点。所以这张图是简单地不得了的。 更特殊地，版本控制中，大多数节点其实入度出度都是一，就像是一个一字长蛇阵。我们在上一章节已经看到了怎么去用commit形成这样的一个一字长蛇阵，因此此处要玩点花样，看看同样频繁使用的分支等功能的实现。

有时间补充