Git 介绍

Git 是什么？

Git 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。也是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持。

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

许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单，但是特别容易犯错。有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。

为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。

这时人们又遇到一个问题，如何让在不同系统上的开发者协同工作？为了解决这个问题，集中化的版本控制系统（Centralized Version Control Systems，CVCS）应运而生。

这类系统都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法。

但此时人们发现，集中化的版本控制系统存在单点问题，如果中央服务器宕机，则在宕机的这段时间所有人都无法提交更新，也就无法协同工作。而如果数据库发生损坏，而有没有及时备份时，所有的数据都将会丢失，只剩下人们在各自机器上保留的单独快照。

为了解决这个问题，分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。

在这类系统中，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。

更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。

直接记录快照，而非差异比较：Git 把数据看作是对小型文件系统的一组快照。每次你提交更新，或在 Git 中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。
近乎所有操作都是本地执行：在 Git 中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其它计算机的信息。
完整性保证：Git 中所有数据在存储前都计算校验和（SHA-1），然后以校验和来引用。这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。
一般只添加数据：你执行的 Git 操作，几乎只往 Git 数据库中增加数据。很难让 Git 执行任何不可逆操作，或者让它以任何方式清除数据。

Git 中文件有四种状态：

状态转移图如下：

Git 中存在三个工作区域：Git 仓库、工作目录以及暂存区域。

Repository（Git 仓库）：是 Git 用来保存项目的元数据和对象数据库的地方。这是 Git 中最重要的部分，从其它计算机克隆仓库时，拷贝的就是这里的数据。
Working Directory（工作目录）：是对项目的某个版本独立提取出来的内容。这些从 Git 仓库的压缩数据库中提取出来的文件，放在磁盘上供你使用或修改。
Staging Area（暂存区）：是一个文件，保存了下次将提交的文件列表信息，一般在 Git 仓库目录中。有时候也被称作`‘索引’’，不过一般说法还是叫暂存区域。

对应上面提到的状态，我们来根据一个 Git 文件的工作流程，来分析一个 Git 文件的状态变化以及所处区域：

我们常用 SVN 与其进行对比，那么它们有什么区别呢？

Git 是分布式的，SVN 不是：这是 Git 和其它非分布式的版本控制系统，例如 SVN，CVS 等，最核心的区别。
Git 把内容按元数据方式存储，而 SVN 是按文件：所有的资源控制系统都是把文件的元信息隐藏在一个类似 .svn、.cvs 等的文件夹里。
Git 分支和 SVN 的分支不同：分支在 SVN 中一点都不特别，其实它就是版本库中的另外一个目录。
Git 没有一个全局的版本号，而 SVN 有：目前为止这是跟 SVN 相比 Git 缺少的最大的一个特征。
Git 的内容完整性要优于 SVN：Git 的内容存储使用的是 SHA-1 哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。