Git重要原理

项目版本库：

        该版本库主要用于存储由“官方”创建并发行的版本。

共享版本库：

        该版本库主要用于开发团队内人员之间的文件交互，在小项目中，项目版本库本身就可以胜任这样的角色。但是在多点开发的条件下我们可能就需要几个这样的专用版本库。

工作流版本库：

        工作流版本库通常用于跳槽哪些代表工作流中某个特定进展状态的修改，例如审核通过之后的状态等。

派生版本库：

        该版本库主要用于从开发主线分离出某部分内容（例如，分离出哪些开发耗时较长，不适合在一个普通发布周期中完成的工作内容），或者隔离出可能永远不会被包含在主线中的、用于实验的那部分开发进展。

        其实，版本库本质上就是一个高效的数据存储结构而已，由以下部分组成。

        文件（即blob）：这里既包含了文本也包含了二进制数据，这些数据将不以文件名的形式被保存。

        目录（即Tree）：目录中保存的是与文件名相关联的内容，其中也会包含其他目录。

        版本（即commit）：每一个版本所定义的都是相应目录的某个可恢复的状态。每当我们创建一个新的版本时，其作者、时间、注释以及其之前的版本都将会被保存下来。对于所有的数据，它们都会被计算成一个十六进制散列值（例如像1632acb65b01c6b621d6e1105205773931bb1a41 这样的值）。这个散列值将会被用作相关对象的引用，以及日后恢复数据时所需的键值（重复的情况是存在的，从数学的角度考虑，可能性是2的63次方分之一）。

        也就是说，一个提交对象的散列值实际上就是它的“版本号”，如果我们持有某一提交的散列值，就可以用它来检查对应版本是否存在于某一版本库中。如果存在，我们就可以将其恢复到当前工作区相应的目录中。如果该版本不存在，我们也可以从其他版本库中单独导入（拉回）该提交所引用的全部对象。

                                                                             图1.1 版本库的对象存储方式

接下来，我们来看看采用这种散列值和这种既定的版本库结构究竟有哪些优势。

       高性能：通过散列值来访问数据是非常快的。

       冗余度—释放存储空间：相同的文件内容只需存储一次即可。

       分布式版本号：由于相关散列值是根据文件，作者和日期来计算的，所以版本也可以“离线”产生，不用担心将来会因此

而发生版本冲突。

        版本库间的高效同步：当我们将某一提交从一个版本库传递给另一个版本库时，只需要传送那些目标版本库中不存在的

对象即可。而正是因为有了散列值的帮助，我们才能很快地判断相关对象是否已经存在。

        数据完整性：由于散列值是根据数据的内容来计算的，所以我们可以随时通过Git 来查看某一散列值是否与相关数据匹

配。以检测该数据上可能的意外变化或恶意操作。

        自动重命名检测：被重命名的文件可以被自动检测到，因为根据该文件内容计算出的散列值并没有发生变化。也正因为

        如此，Git 中并没有专用的重命名命令，只需移动命令即可。