1.为什么要用Git
Git的背后有着一个非常精彩的成功故事。2005年4月，Linux Torvalds因不满当时任何一个可用的开源版本控制系统，就亲自着手实现了Git。在今天看来，Git已经俨然成为了新型开源项目的一个标准，许多大型的开源项目都已经或正在计划迁移到Git上来。
我们来看看这么多人之所以会选择Git的原因：
Git允许我们利用分支来开展工作： 在一个由多个开发者并行协作的项目中，开发者各自会有很多不同的开发路线。Git的优势在于，它提供了一整套针对开发链的重新整合工具，以便我们对其进行合并、变基和捡取等操作。
工作流上的灵活性： Git非常灵活。不但单一开发者可以用它。敏捷团队也可以找到它工作的合适方法，甚至一个由众多开发者在不同的工作地点参与的大型国际项目也可以用它开发出一个很好的工作流。
适合奉献合作： 大多数的开源项目所依靠的都是开发者的无私奉献，如果我们使用Git，那么每个人都先可以克隆一个独立的工作版本库，然后再对其进行后续的改动。
高性能： Git在处理拥有许多文件且历史悠久的项目时速度也依然是非常快的。例如，使用Git将Linux内核源码的当前版本切换到6年前的旧版本时，在一台MacBook Air上所需的时间不到1分钟，而这两个版本之间有着超过200000次的提交和40000个更改文件。
强大的抗故障和抗攻击能力： 由于项目被分散存储在多个分布式版本库中，因此数据严重流失的可能性不大。而且，它还使用了统一的加密校验，这使得攻击者难以对版本库进行篡改。
离线开发与多点开发： 分布式的体系结构可以使得离线开发或者边旅行边开发的方式变得非常容易，而且在多点开发模式下，既不需要设置中央服务器，也不需要固定的网络连接。
强大的开源社区： 除官方提供的详细文档外，你还可以在该社区找到无数相关的手册、论坛、维基网站等，另外还有各种工具生态系统、托管平台、出版物、服务以及针对各个开发环境的插件，整个社区都正在茁壮成长。
可扩展性： Git为用户提供了许多实用命令，其中包括了能使我们更便于直接访问其远程版本库的命令
2.分布式版本控制与集中式版本控制的对比
对于集中式版本控制系统（例如CVS或Subversion）来说，每个开发者都在他自己的计算机上有一个包含所有项目文件的工作目录（即工作区）。当该开发者在本地做了修改之后，他就会定期将修改提交给某台中央服务器。然后，开发者在执行更新操作的同时也会从该服务器上捡取出其他开发者所做的修改。这台中央服务器上存储着这些文件（即版本库）的当前版本和历史版本。因此，这些被并行开发的分支，以及各种被命名（标记）的版本都将会被集中管理。
而在分布式版本控制系统中，开发者环境与服务器环境之间是没有分隔的。每一个开发者都同时拥有一个用于当前文件操作的工作区与一个用于存储该项目所有版本、分支以及标签的本地版本库（我们称其为一份克隆）。每个开发者的修改都会被载入成一次次的新版本提交（commit），首先提交到其本地版本库中。然后，其他开发者就会立即看到新的版本。通过推送（push）和拉回（pull）命令，我们可以将这些修改从一个版本库传送到另一个版本库中。这样一来，从技术上来看，这里所有的版本库在分布式架构上的地位是同等的。因此从理论上讲，我们不再需要借助服务器，就可以将某一台开发工作机上所做的所有修改直接传送给另一开发工作机。当然在具体实践中，Git中的服务器版本库也扮演了重要的角色，例如以下这些特型版本库：
项目版本库（blessed repository）： 该版本库主要用于存储由“官方”创建并发行的版本。
共享版本库（shared repository）： 该版本库主要用于开发团队内人员之间的文件交换。在小型项目中，项目版本库本身就可以胜任这一角色了。但在多点开发的条件下，我们可能就会需要几个这样的专用版本库。
工作流版本库（workflow repository）： 工作流版本库通常只用于填充那些代表工作流中某种特定进展状态的修改，例如审核通过后的状态等。
- 派生版本库（fork repository）： 该版本库主要用于从开发主线分离出某部分内容（例如，分离出那些开发耗时较长，不适合在一个普通发布周期中完成的内容），或者隔离出可能永远不会被包含在主线中的、用于实验的那部分开发进展。
那么，分布式系统相对于集中式的优点有哪些呢。
高性能： 几乎所有的操作都无需进行网络访问，均可直接在本地执行。
高效的工作方式： 开发者可通过多个本地分支在不同任务之间快速切换。
离线功能： 开发者可以在没有服务器连接的情况下执行提交、创建分支、版本标签等操作。之后再将其上传到服务器。
灵活的开发进程： 我们可以在团队和公司中为其他部门建立专用的版本库，例如为方便与测试人员交流而建的脚本库。这样相关修改就很容易发布，因为只是特定版本库上的一次推送。
备份作用： 由于每个开发者都持有一份拥有完整历史版本的版本库副本，所以因服务器故障而导致数据丢失的可能性是微乎其微的。
可维护性： 对于那些难以对付的重构工作，我们可以在将成功传送给其原始版本库之前，先在该版本库的副本上尝试一下。
3.什么是版本库
其实，版本库本质上就是一个高效的数据存储结构而已，由以下部分组成。
文件（blob）： 这里既包含了文本也包含了二进制数据，这些数据将不以文件名的形式被保存。
目录（Tree）： 目录中保存的是与文件名相关联的内容，其中也会包含其他目录。
版本（commit）： 每一个版本所定义的都是相应目录的某个可恢复的状态。每当我们创建一个新的版本时，其作者、时间、注释以及其之前的版本都将会保存下来。
对于所有的数据，它们都会被计算成一个十六进制散列值，这个散列值将会被用作相关对象的引用，以及日后恢复数据是所需的键值。
也就是说，一个提交对象的散列值实际上就是它的“版本号”，如果我们持有某一提交的散列值，就可以用它来检查对应版本是否存在某一版本库中。如果存在，我们就可以将其恢复都当前工作区相应的目录中。如果该版本不存在，我们也可以从其他版本库中单独导入（拉回）该提交所引用的全部对象。