Git学习指南 - (EPUB全文下载)

文件大小：0.21 mb。
文件格式：epub 格式。
书籍内容：

Git学习指南
第1章 基本概念
第2章 入门
第3章 提交究竟是什么
第4章 多次提交
第5章 版本库
第6章 分支
第7章 合并分支
第8章 通过变基净化历史
第9章 版本库间的交换
第10章 版本标签
第11章 版本库之间的依赖
第12章 技巧
第13章 工作流简介
第14章 项目设置
第15章 相同分支上的开发
第16章 基于特性分支的开发
第17章 二分法排错
第18章 基于构建服务器的工作
第19章 发行版交付
第20章 拆分大项目
第21章 合并小型项目
第22章 外包长历史记录
第23章 与其他版本控制系统并行使用
第24章 迁移到Git
第25章 还有一些其他任务
第26章 Git的缺点
欢迎来到异步社区！
第1章　基本概念
在本章中，我们将介绍一个分布式版本控制系统的设计思路，以及它与集中式版本控制系统的不同之处。除此之外，我们还将带你了解分布式版本库的具体工作方式，以及为什么我们会说，在Git中创建分支和合并分支不是个大不了的问题。
1.1　分布式版本控制，有何过人之处
在具体探讨分布式版本控制的概念之前，让我们先来快速回顾一下传统的集中式版本控制架构。
图1.1中所显示的就是一个集中式版本控制系统（例如CVS或Subversion）的典型布局。每个开发者都在他或她自己的计算机上有一个包含所有项目文件的工作目录（即工作区）。当该开发者在本地做了修改之后，他或她就会定期将修改提交给某台中央服务器。然后，开发者在执行更新操作的同时也会从该服务器上捡取出其他开发者所做的修改。这台中央服务器上存储着这些文件（即版本库）的当前版本和历史版本。因此，这些被并行开发的分支，以及各种被命名（标记）的版本都将会被集中管理。
图1.1　集中式版本控制
而在分布式版本控制系统（见图1.2）中，开发者环境与服务器环境之间是没有分隔的。每一个开发者都同时拥有一个用于当前文件操作的工作区与一个用于存储该项目所有版本、分支以及标签的本地版本库（我们称其为一份克隆）。每个开发者的修改都会被载入成一次次的新版本提交(commit), 首先提交到其本地版本库中。然后，其他开发者就会立即看到新的版本。通过推送（push）和拉回（pull）命令，我们可以将这些修改从一个版本库传送到另一个版本库中。这样一来，从技术上来看，这里所有的版本库在分布式架构上的地位是同等的。因此从理论上来讲，我们不再需要借助服务器，就可以将某一台开发工作机上所做的所有修改直接传送给另一开发工作机。当然在具体实践中，Git中的服务器版本库也扮演了重要的角色，例如以下这些特型版本库。
图1.2　分布式版本控制
项目版本库（blessed repository）：该版本库主要用于存储由“官方”创建并发行的版本。
共享版本库（shared repository）：该版本库主要用于开发团队内人员之间的文件交换。在小型项目中，项目版本库本身就可以胜任这一角色了。但在多点开发的条件下，我们可能就会需要几个这样的专用版本库。
工作流版本库（workflow repository）：工作流版本库通常只用于填充那些代表工作流中某种特定进展状态的修改，例如审核通过后的状态等。
派生版本库（fork repository）：该版本库主要用于从开发主线分离出某部分内容（例如，分离出那些开发耗时较长，不适合在一个普通发布周期中完成的内容），或者隔离出可能永远不会被包含在主线中的、用于实验的那部分开发进展。
下面，我们再来看看分布式系统相对于集中式的优点有哪些。
高性能：几乎所有的操作都无需进行网络访问，均可直接在本地执行。
高效的工作方式：开发者可通过多个本地分支在不同任务之间进行快速切换。
离线功能：开发者可以在没有服务器连接的情况下执行提交、创建分支、版本标签等操作。之后再将其上传服务器。
灵活的开发进程：我们可以在团队和公司中为其他部门建立专用的版本库，例如为方便与测试人员交流而建的版本库。这样相关修改就很容易发布，因为只是特定版本库上的一次推送。
备份作用：由于每个开发者都持有一份拥有完整历史版本的版本库副本，所以因服务器故障而导致数据丢失的可能性是微乎其微的。
可维护性：对于那些难以对付的重构工作，我们可以在将成功传送给其原始版本库之前，先在该版本库的副本上尝试一下。
1.2　版本库，分布式工作的基础所在
其实，版本库本质上就是一个高效的数据存储结构而已，由以下部分组成。
文件（即blob）：这里既包含了文本也包含了二进制数据，这些数据将不以文件名的形式被保存。
目录（即Tree）：目录中保存的是与文件名相关联的内容，其中也会包含其他目录。
版本（即commit）：每一个版本所定义的都是相应目录的某个可恢复的状态。每当我们创建一个新的版本时，其作者、时间、注释以及其之前的版本都将会被保存下来。
对于所有的数据，它们都会被计算成一个十六进制散列值（例如像1632acb65b01 c6b621d6e1105205773931bb1a41这样的值）。这个散列值将会被用作相关对象的引用，以及日后恢复数据时所需的键值（见图1.3）。
图1.3　版本库中的对象存储
也就是说，一个提交对象的散列值实际上就是它的“版本号”，如果我们持有某一提交的散列值，就可以用它来检查对应版本是否存在于某一版本库中。如果存在，我们就可以将其恢复到当前工作区相应的目录中。如果该版本不存在，我们也可以从其他版本库中单独导入（拉回）该提交所引用的全部对象。
接下来，我们来看看采用这种散列值和这种既定的版本库结构究竟有哪些优势。
高性能：通过散列值来访问数据是非常快的。
冗余度——释放存储空间：相同的文件内容只需存储一次即可。
分布式版本号：由于相关散列值是根据文件，作者和日期来计算的，所以版本也可以“离线”产生，不用担心将来会因此而发生版本冲突。
版本库间的高效同步：当我们将某一提交从一个版本库传递给另一个版本库时，只需要传送那些目标版本库中不存在的对象即可。而正是因为有了散列值的帮助，我们才能很快地判断 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。