Git基本原理（一）——Git基础

Git基本原理（一）——Git基础

Git的思想和原理与其它版本控制系统（如Subversion）有很大差别，我们可以在短时间内快速学习并在项目中应用Git，但只是能进行相对简单的操作，只有真正理解Git的工作原理后，才能在进行Git操作时游刃有余。

Git

Git是一个分布式的版本控制系统。

版本控制系统是一种记录一个或若干文件内容变化，以便将来查阅特定版本修改情况的系统。

版本控制系统历经了本地版本控制系统、集中式版本控制系统、分布式的版本控制系统的发展过程。

本地版本控制系统可以管理本地的文件却无法实现多人协作

集中式版本控制系统使用一台中央服务器来保存修改内容，不同协作者通过连接中央服务器来获取他人的修改实现多人协作。但是中央服务器如果出现故障就会导致无法提交修改甚至丢失修改。

分布式控制系统不同与集中式版本控制只是提取最新版本的文件快照，而是将整个仓库完整的镜像下来，发生单点故障后可以从任何镜像出来的仓库恢复。

Git特性

很多年来，集中式的版本控制系统都是协同工作的标准做法，分布式控制系统发展成熟后正逐渐取代集中式版本控制系统。

我们常常会讨论和使用Git，但是分布式版本控制系统并不是只有Git，还有Mercurial、Bazaar、Darcs等，Git为什么能够脱颖而出呢？这和Git的设计理念及拥有的特性有很大关系。

Git特性：

• 完全分布式（协同合作、不担心单点故障）
• 执行速度快（几乎所有操作都能在秒级完成）
• 非线性开发模式的强力支持（允许成千上万个并行开发的分支）
• 大型项目管理（得益执行速度和非线性开发模式的强力支持，大型项目不会有大量的冗余和复杂的计算）
• 简单易用（短时间的了解就可以简单的快速的应用）
• 强大的社区（意味着更容易找到使用问题的解答，更快的漏洞修复，更新的特性支持）

Git的操作方式

近乎所有操作都是本地执行

在 Git 中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其它计算机的信息。 因为在本地磁盘上有项目的完整历史，所以大部分操作看起来瞬间完成。

这也意味着当你无法连接远程仓库时，几乎可以进行任何操作，你可以正常地提交，直到连接上远程仓库时再上传。 使用其它系统,做到如此是不可能或很费力的。 比如，用 Perforce，你没有连接服务器时几乎不能做什么事;用 Subversion 和 CVS，你能修改文件，但不能向数据库提交修改(因为你的本地数据库离线了)。

这为我们随时随地工作提供了可能性。

Git 如何保证完整性

Git 中所有数据在存储前都计算校验和，然后以校验和来引用。

这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 这个功能建构在 Git 底层，是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件，Git 就能发现。
Git 用以计算校验和的机制叫做 SHA-1 散列(hash，哈希)。 这是一个由 40 个十六进制字符(0-9 和 a-f)组
成字符串，基于 Git 中文件的内容或目录结构计算出来。 SHA-1 哈希看起来是这样：24b9da6552252987aa493b52f8696cd6d3b00373。Git 中使用这种哈希值的情况很多，你将经常看到这种哈希值。 Git 数据库中保存的信息都是以文件内容的哈希值来索引，而不是文件名。

三种状态

如果想要理解Git的操作的原理，了解Git三种状态以及引入的三个工作区域至关重要。

Git 有三种状态：

• 已提交(committed)
• 已修改(modified)
• 已暂存(staged)

Git项目中的三个工作区域

• Git仓库
• 工作目录
• 暂存区

Git仓库是 Git 用来保存项目的元数据和对象数据库的地方。 这是 Git 中最重要的部分,从其它计算机克隆
仓库时，拷贝的就是这里的数据。已保存在Git仓库的数据状态为已提交。
工作目录是对项目的某个版本独立提取出来的内容。 这些从 Git 仓库的压缩数据库中提取出来的文件，放在磁盘
上供你使用或修改。在工作目录中对一个以追踪文件进行修改，但还没做进行后续操作，文件状态就会变为已修改。

暂存区是一个文件，保存了下次将提交的文件列表信息，一般在 Git 仓库目录中。对已修改的文件进行标记，则文件状态变化为已暂存，被标记的文件会包含在下次提交的快照中，当执行提交操作时会将快照保存到Git仓库中。

因此基本的 Git 工作流程如下:

1. 在工作目录中修改文件。

2. 暂存文件，将文件的快照放入暂存区域。

3. 提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库。

Git如何对待数据

直接记录快照,而非差异比较

Git 和其它版本控制系统(如Subversion)的主要差别在于 Git 对待数据的方法。

传统版本控制系统以文件变更列表的方式存储信息。 这类系统将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。

Git 不按照以上方式对待或保存数据，Git 对待数据更像是一个快照流。

每次你提交更新或在Git中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。 为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。

这是 Git 与几乎所有其它版本控制系统的重要区别。Git 重新考虑了以前每一代版本控制系统延续下来的诸
多方面。 Git 更像是一个小型的文件系统，提供了许多以此为基础构建的超强工具，而不只是一个简单的 VCS。

Git对象

我们已经知道了Git仓库保存的数据时一系列文件的快照，接下来再来了解一下他们是怎么关联的。在进行提交操作时，Git会保存一个提交对象(commit object)。

这个提交对象包含：

• 对象的大小

• 树对象（记录项目的文件结构）指针

• 指向它的父对象（首次提交没有，合并时有多个）的指针

• 作者

• 提交者

• 提交时填写的注释

一个树对象（tree object）包含：

• 文件大小
• tree对象（记录下级目录的文件结构）指针
• blob对象（文件版本快照）指针

为了更加形象地说明，我们假设现在有一个工作目录，里面包含了三个将要被暂存和提交的文件。 暂存操作会为每一个文件计算校验和(使用我们在 起步 中提到的 SHA-1 哈希算法)，然后会把当前版本的文件快照保存到Git 仓库中(Git 使用 blob 对象来保存它们)，最终将校验和加入到暂存区域等待提交。普通的commit对象关系如下所示：

使用 git log 可以查看commit对象，使用 git cat-file -p ObjectID 可以查看对象中的内容。

命令行

Git 有多种使用方式。 可以使用原生的命令行模式，也可以使用 GUI （图形用户界面）模式。

如果想要很好的使用Git，一定要掌握命令行模式，因为只有在命令行模式下才能执行 Git 的所有命令。 如果你学会了在命令行下如何操作，那么你在操作 GUI 软件时应该也不会遇到什么困难，但是，反之则不成立。

而大多数的 GUI 软件只实现了Git 所有功能的一个子集以降低操作难度。 此外，GUI软件的操作方式不尽相同，不同的人常常会安装不同的 GUI 软件，但所有人一定会有命令行工具，也就意味着只要掌握命令行，就不要担心是否会操作电脑中安装的GUI软件。

参考书目：

• 《Pro Git》