Git 的核心概念

本文不是Git使用教学篇，而是偏向理论方面，旨在更加深入的理解Git，这样才能更好的使用它，让工具成为咱们得力的助手。

版本控制系统

Git 是目前世界上最优秀的分布式版本控制系统。版本控制系统是可以随着时间的推动记录一系列文件的变化以便于你之后想要的退回到某个版本的系统。版本控制系统分为三大类：本地版本控制系统，集中式版本控制系统和分布式版本控制系统

本地版本控制（Local Version Control Systems）是将文件的各个版本以必定的数据格式存储在本地的磁盘（有的VCS 是保存文件的变化补丁，即在文件内容变化时计算出差量保存起来），这种方式在必定程度上解决了手动复制粘贴的问题，但没法解决多人协做的问题。

本地版本控制

集中式版本控制（Centralized Version Control Systems）相比本地版本控制没有什么本质的变化，只是多了个一个中央服务器，各个版本的数据库存储在中央服务器，管理员能够控制开发人员的权限，而开发人员也能够从中央服务器拉取数据。集中式版本控制虽然解决了团队协做问题，但缺点也很明显：全部数据存储在中央服务器，服务器一旦宕机或者磁盘损坏，会形成不可估量的损失。

集中式版本控制

分布式版本控制（ Distributed Version Control System）与前二者均不一样。首先，在分布式版本控制系统中，像 Git，Mercurial，Bazaar 以及 Darcs 等，系统保存的的不是文件变化的差量，而是文件的快照，即把文件的总体复制下来保存，而不关心具体的变化内容。其次，最重要的是分布式版本控制系统是分布式的，当你从中央服务器拷贝下来代码时，你拷贝的是一个完整的版本库，包括历史纪录，提交记录等，这样即便某一台机器宕机也能找到文件的完整备份。

分布式版本控制

Git基础

Git是一个分布式版本控制系统，保存的是文件的完整快照，而不是差别变化或者文件补丁。

保存每一次变化文件的完整内容

Git每一次提交都是对项目文件的一个完整拷贝，所以你能够彻底恢复到之前的任一个提交而不会发生任何区别。这里有一个问题：若是个人项目大小是10M，那Git占用的空间是否是随着提交次数的增长线性增长呢？我提交（commit）了10次，占用空间是否是100M呢？很显然不是，Git是很智能的，若是文件没有变化，它只会保存一个指向上一个版本的文件的指针，即，对于一个特定版本的文件，Git只会保存一个副本，但能够有多个指向该文件的指针。

另外注意，Git最适合保存文本文件，事实上Git就是被设计出来就是为了保存文本文件的，像各类语言的源代码，由于Git能够对文本文件进行很好的压缩和差别分析（你们都见识过了，Git的差别分析能够精确到你添加或者删除了某个字母）。而二进制文件像视频，图片等，Git也能管理，但不能取得较好的效果（压缩比率低，不能差别分析）。实验证实，一个 500k 的文本文件经Git压缩后仅 50k 左右，稍微改变内容后两次提交，会有两个 50k 左右的文件，没错的，保存的是完整快照。而对于二进制文件，像视频，图片，压缩率很是小， Git 占用空间几乎随着提交次数线性增加。

未变化的文件只保存上一个版本的指针

Git工程有三个工做区域：工做目录，暂存区域，以及本地仓库。工做目录是你当前进行工做的区域；暂存区域是你运行git add命令后文件保存的区域，也是下次提交将要保存的文件（注意：Git 提交实际读取的是暂存区域的内容，而与工做区域的文件无关，这也是当你修改了文件以后，若是没有添加git add到暂存区域，并不会保存到版本库的缘由）；本地仓库就是版本库，记录了你工程某次提交的完整状态和内容，这意味着你的数据永远不会丢失。

相应的，文件也有三种状态：已提交（committed），已修改（modified）和已暂存（staged）。已提交表示该文件已经被安全地保存在本地版本库中了；已修改表示修改了某个文件，但尚未提交保存；已暂存表示把已修改的文件放在下次提交时要保存的清单中，即暂存区域。因此使用Git的基本工做流程就是：

1. 在工做区域增长，删除或者修改文件。
2. 运行git add，将文件快照保存到暂存区域。
3. 提交更新，将文件永久版保存到版本库中。
   

Git对象

如今已经明白Git的基本流程，但Git是怎么完成的呢？Git怎么区分文件是否发生变化？下面简单介绍一下Git的基本原理。

SHA-1 校验和

Git 是一套内容寻址文件系统。意思就是Git 从核心上来看不过是简单地存储键值对（key-value），value是文件的内容，而key是文件内容与文件头信息的 40个字符长度的 SHA-1 校验和，例如：5453545dccD33565a585ffe5f53fda3e067b84d8。Git使用该校验和不是为了加密，而是为了数据的完整性，它能够保证，在不少年后，你从新checkout某个commit时，必定是它多年前的当时的状态，彻底一摸同样。当你对文件进行了哪怕一丁点儿的修改，也会计算出彻底不一样的 SHA-1 校验和，这种现象叫作“雪崩效应”（Avalanche effect）。

SHA-1 校验和所以就是上文提到的文件的指针，这和C语言中的指针颇有些不一样：C语言将数据在内存中的地址做为指针，Git将文件的 SHA-1 校验和做为指针，目的都是为了惟一区分不一样的对象。可是当C语言指针指向的内存中的内容发生变化时，指针并不发生变化，但Git指针指向的文件内容发生变化时，指针也会发生变化。因此，Git中每个版本的文件，都有一个惟一的指针指向它。

文件(blob)对象，树(tree)对象，提交(commit)对象

blob 对象保存的仅仅是文件的内容，tree 对象更像是操做系统中的文件夹，它能够保存blob对象和tree 对象。一个单独的 tree 对象包含一条或多条 tree 记录，每一条记录含有一个指向 blob 对象或子 tree 对象的 SHA-1 指针，并附有该对象的权限模式 (mode)、类型和文件名信息等：

当你对文件进行修改并提交时，变化的文件会生成一个新的blob对象，记录文件的完整内容（是所有内容，不是变化内容），而后针对该文件有一个惟一的 SHA-1 校验和，修改这次提交该文件的指针为该 SHA-1 校验和，而对于没有变化的文件，简单拷贝上一次版本的指针即 SHA-1 校验和，而不会生成一个全新的blob对象，这也解释了10M大小的项目进行10次提交总大小远远小于100M的缘由。

另外，每次提交可能不只仅只有一个 tree 对象，它们指明了项目的不一样快照，但你必须记住全部对象的 SHA-1 校验和才能得到完整的快照，并且没有做者，什么时候，为何保存这些快照的缘由。commit对象就是问了解决这些问题诞生的，commit 对象的格式很简单：指明了该时间点项目快照的顶层tree对象、做者/提交者信息（从 Git 设置的 user.name 和 user.email中得到)以及当前时间戳、一个空行，上一次的提交对象的ID以及提交注释信息。你能够简单的运行git log来获取这新信息：

$ git log
commit 2cb0bb475c34a48957d18f67d0623e3304a26489 Author: lufficc <luffy.lcc@gmail.com> Date: Sun Oct 2 17:29:30 2016 +0800 fix some font size commit f0c8b4b31735b5e5e96e456f9b0c8d5fc7a3e68a Author: lufficc <luffy.lcc@gmail.com> Date: Sat Oct 1 02:55:48 2016 +0800 fix post show css ***********省略***********

上图的Test.txt是第一次提交以前生成的，第一次它的初始 SHA-1 校验和以3c4e9c开头。随后对它进行了修改，因此第二次提交时生成了一个全新blob对象，校验和以1f7a7a开头。而第三次提交时Test.txt并无变化，因此只是保存最近版本的 SHA-1 校验和而不生成全新的blob对象。在项目开发过程当中新增长的文件在提交后都会生成一个全新的blob对象来保存它。注意除了第一次每一个提交对象都有一个指向上一次提交对象的指针。

所以简单来讲，blob对象保存文件的内容；tree对象相似文件夹，保存blob对象和其它tree对象；commit对象保存tree对象，提交信息，做者，邮箱以及上一次的提交对象的ID（第一次提交没有）。而Git就是经过组织和管理这些对象的状态以及复杂的关系实现的版本控制以及以及其余功能如分支。

Git引用

如今再来看引用，就会很简单了。若是咱们想要看某个提交记录以前的完整历史，就必须记住这个提交ID，但提交ID是一个40位的 SHA-1 校验和，难记。因此引用就是SHA-1 校验和的别名，存储在.git/refs文件夹中。

最多见的引用也许就是master了，由于这是Git默认建立的（能够修改，但通常不修改），它始终指向你项目主分支的最后一次提交记录。若是在项目根目录运行cat .git/refs/heads，会输出一个SHA-1 校验和，例如：

$ cat .git/refs/heads/master
4f3e6a6f8c62bde818b4b3d12c8cf3af45d6dc00

所以master只是一个40位SHA-1 校验和的别名罢了。

还有一个问题，Git如何知道你当前分支的最后一次的提交ID?在.git文件夹下有一个HEAD文件，像这样：

$ cat .git/HEAD
ref: refs/heads/master

HEAD文件其实并不包含 SHA-1 值，而是一个指向当前分支的引用，内容会随着切换分支而变化，内容格式像这样：ref: refs/heads/<branch-name>。当你执行git commit命令时，它就建立了一个commit对象，把这个commit对象的父级设置为HEAD 指向的引用的 SHA-1 值。

再来讲说 Git 的 tag，标签。标签从某种意义上像是一个引用， 它指向一个 commit 对象而不是一个 tree，包含一个标签，一组数据，一个消息和一个commit 对象的指针。可是区别就是引用随着项目进行它的值在不断向前推动变化，可是标签不会变化——永远指向同一个 commit，仅仅是提供一个更加友好的名字。

Git分支

分支

分支是Git的杀手级特征，并且Git鼓励在工做流程中频繁使用分支与合并，哪怕一天以内进行许屡次都没有关系。由于Git分支很是轻量级，不像其余的版本控制，建立分支意味着要把项目完整的拷贝一份，而Git建立分支是在瞬间完成的，而与你工程的复杂程度无关。

由于在上文中已经说到，Git保存文件的最基本的对象是blob对象，Git本质上只是一棵巨大的文件树，树的每个节点就是blob对象，而分支只是树的一个分叉。说白了，分支就是一个有名字的引用，它包含一个提交对象的的40位校验和，因此建立分支就是向一个文件写入 41 个字节（外加一个换行符）那么简单，因此天然就快了，并且与项目的复杂程度无关。

Git的默认分支是master，存储在.git\refs\heads\master文件中，假设你在master分支运行git branch dev建立了一个名字为dev的分支，那么git所作的实际操做是：

1. 在.git\refs\heads文件夹下新建一个文件名为dev（没有扩展名）的文本文件。
2. 将HEAD指向的当前分支（当前为master）的40位SHA-1 校验和外加一个换行符写入dev文件。
3. 结束。

建立分支就是这么简单，那么切换分支呢？更简单：

1. 修改.git文件下的HEAD文件为ref: refs/heads/<分支名称>。
2. 按照分支指向的提交记录将工做区的文件恢复至如出一辙。
3. 结束。

记住，HEAD文件指向当前分支的最后一次提交，同时，它也是以当前分支再次建立一个分支时，将要写入的内容。

分支合并

再来讲一说合并，首先是Fast-forward，换句话说，若是顺着一个分支走下去能够到达另外一个分支的话，那么 Git 在合并二者时，只会简单地把指针右移，由于这种单线的历史分支不存在任何须要解决的分歧，因此这种合并过程能够称为快进（Fast forward）。好比：

注意箭头方向，由于每一次提交都有一个指向上一次提交的指针，因此箭头方向向左，更为合理

当在master分支合并dev分支时，由于他们在一条线上，这种单线的历史分支不存在任何须要解决的分歧，因此只须要master分支指向dev分支便可，因此很是快。

当分支出现分叉时，就有可能出现冲突，而这时Git就会要求你去解决冲突，好比像下面的历史：

由于master分支和dev分支不在一条线上，即v7不是v5的直接祖先，Git 不得不进行一些额外处理。就此例而言，Git 会用两个分支的末端（v7 和 v5）以及它们的共同祖先（v3）进行一次简单的三方合并计算。合并以后会生成一个和并提交v8：

注意：和并提交有两个祖先（v7和v5）。

分支的变基rebase

把一个分支中的修改整合到另外一个分支的办法有两种：merge 和 rebase。首先merge 和 rebase最终的结果是同样的，但rebase能产生一个更为整洁的提交历史。仍然以上图为例，若是简单的merge，会生成一个提交对象v8，如今咱们尝试使用变基合并分支，切换到dev：

$ git checkout dev
$ git rebase master
First, rewinding head to replay your work on top of it... Applying: added staged command

这段代码的意思是：回到两个分支最近的共同祖先v3，根据当前分支（也就是要进行变基的分支 dev）后续的历次提交对象（包括v4，v5），生成一系列文件补丁，而后以基底分支（也就是主干分支 master）最后一个提交对象（v7）为新的出发点，逐个应用以前准备好的补丁文件，最后会生成两个新的合并提交对象（v4'，v5'）,从而改写 dev 的提交历史，使它成为 master 分支的直接下游，以下图：

如今，就能够回到master分支进行快速合并Fast-forward了，由于master分支和dev分支在一条线上：

$ git checkout master
$ git merge dev

如今的v5'对应的快照，其实和普通的三方合并，即上个例子中的 v8 对应的快照内容如出一辙。虽然最后整合获得的结果没有任何区别，但变基能产生一个更为整洁的提交历史。若是视察一个变基过的分支的历史记录，看起来会更清楚：仿佛全部修改都是在一根线上前后进行的，尽管实际上它们本来是同时并行发生的。

总结

一、Git保存文件的完整内容，不保存差量变化。

二、Git以储键值对（key-value）的方式保存文件。

三、每个文件，相同文件的不一样版本，都有一个惟一的40位的 SHA-1 校验和与之对应。

四、SHA-1 校验和是文件的指针，Git依靠它来区分文件。

五、每个文件都会在Git的版本库里生成blob对象来保存。

六、对于没有变化的文件，Git只会保留上一个版本的指针。

七、Git其实是经过维持复杂的文件树来实现版本控制的。

八、使用Git的工做流程基本就是就是文件在三个工做区域之间的流动。

九、应该大量使用分支进行团队协做。

十、分支只是对提交对象的一个引用。

原文地址：http://www.codeceo.com/article/git-core-concept.html