Technology changes the world of life

在下图中，我们将会看到开发阶段和发布阶段各自所需要的分支。如你所见，开发部分被放在了master 分支上。无论有没有设置feature 分支 ，master 分支都是决定将哪一些代码纳入发行版的唯一主角。在预备发布阶段，我们会将启用一个独立的 codefreeze 分支，以便稳定住将要发布的版本。与此同时， master 分支上下一版本的开发工作将继续进行。一旦稳定阶段的工作完成，我们就可以在 stable 分支上创建一个发行版提交，并同时生成一个相应的发行版标签。

对于本章的工作流来说，其大脑部分就是构建服务器(见下图)。在这些需定期构建的版本库中，构建服务器通常会交由中央版本库的 master 分支中的最新提交来负责配置。而在构建服务器中，这些构建和测试代码只是它的输入源。在构建服务器中，我们通常会设置两个分支。其中，last-build 分支会直接指向 master 分支中最后构建成功的那个版本。而 buildhistory 分支中则将会包含该软件所有被成功构建的版本。last-build 分支中的内容会在每次中央版本库成功完成构建时被传送给构建服务器。

在下图中，我们将会看到一段提交历史，其中有一个确认无误的提交和已明确出了问题的提交。虽然提交历史并不非得要线性发展，但在出了问题的提交到没有问题的提交之间必须要有一条路径，以说明它们之间的父系关系。当二分查找进程被启动之后， Git 就会在相关的提交历史的中间位置选择一个合适的提交。该提交将会被执行某种人工测试或脚本测试，然后根据其结果被标记为“good”或“had”。接着，该二分查找任务会去挑选另一个提交对象，对其进行测试并标记。这个进程会一直重复该动作，直至找到其直系父提交中没有错误的那次提交。

在下图中，我们会看到本章工作流的基本结构，那就是一个团队在特性分支上开发时会创建的工作流。他们会从master分支着手，为每个特性或错误修复都创建一个新的分支(bug 在下面没有被明确地列出来)。该分支会被用于执行所有的修改和改进。一旦该特性已经可以被集成到master分支上时，我们只需要对其执行一次合并即可。当然这里务必要小心一件事，该合并操作必须要在master分支上发起，并且不能使用快进式合并。这样我们就能在master分支上得到一个清晰的第一父级历史，因为该分支上将只包含特性分支的合并提交。

在下图中，我们会看到本章工作流的典型使用情况。如你所见，中央版本库位于该图的顶部，底部则是开发者A 和开发者B 的版本库。每个开发者都会从自己的master分支开始着手，所产生出小型的增量提交必须要能够返回到之前的状态，并将自己的步骤文档化。一旦任务完成，或者有其他开发者所需要的中间层代码，该提交就会通过push命令被传送到中央版本库中。只要在此期间，中央版本库的master分支没有发生变化，该push命令就会成功被执行。但通常情况下，中央版本库的master分支上应该还会有来自其他开发者的提交。

一旦我们决定了要在项目中使用 Git, 首先要做的第一步就是为其 Git 版本库分配相应 的文件与目录。这一步的重点是我们要决定被版本化的项目是要用单一版本库还是多个版本库。由于Git 版本库中只能创建分支和标签，这在很大程度上也等于是在决定该项目的发布单元。待划分完项目后，我们还得要为每个模块建立相应的版本库并对其进行填充。当然，空目录与尚未被版本化的文件会被特殊对待。在进行团队协作时，我们还必须要为各模块定义一个中央版本库。

在这一章中，我们将会带你来看一组技巧。这些技巧中的一些在特定情况下是非常有用的，但我们也有可能永远都会不需要它们。因此，或许你可 以先粗略地浏览一下本章，充分了解一下这里所涉及的内容。然后在真正需要它们时，再回过头来看具体细节。

嵌入子模块：我们可以通过和命令来嵌入一个子模块。克隆包含子模块的项目：我们可以在克隆该项目后，对其调用和命令。选择子模块中的某个新版本：首先，我们要(通过checkout命令来看) 选择在子模块目录中的新提交。然后，在主版本库中对其做一次提交。同时处理模块版本库与主版本库：我们必须要先在模块版本库中执行提交，然后才能在主版本库中执行提交。另外，两个版本库的推送操作也必须要各自执行push命令。嵌入子树：我们可以通过命令来嵌入子树。选择子树中的某个新版本：我们可以通过。

创建标签：即用 tag 命令来创建标签。推送：push 命令可以只用来传送那些被明确指定的标签，例如这样, 当然，如果我们使用了-tags参数就不用指定标签了。拉回与获取pull和fetch这两个命令都会自动获取其所涉及分支中的所有标签，除非我们在命令中使用了--no-tags参数。显示所有标签：这件事可以通过git tag -l命令来完成。在日记中显示标签：我们可以使用命令。共享标签中的提交：如果想要知道某一标签中是否包含了某一提交，我们可以用带-contains参数的 tag 命令。

版本库URL: 即以URL 的格式指示远程版本库所在的位置，例如。该 URL 支持以下协议：file 、ssh 、http 、https 、ftp 、ftps 、rsync 和git。昵称：我们可以用remote命令为版本库定义一个昵称，这样一来，我们每次在需要访问该版本库是就不必指定那么长的URL 了。获取fetch命令可从远程版本的分支上获取提交。当然，它只能用于传送那些还不 在本地的提交。无参数获取：该操作将检索远程版本库上所有分支上的提交。不移动本地分支的获取。

变基操作：Git 能将提交复制到提交图中的其他地方。尽管其中的修改与元数据(作者、日期)将保持不变，但该复制结果会有一个新的提交散列值。你可以通过rebase命令以多种方式对提交图进行重构。只适用于推送之前：通常情况下，我们应该只对那些还未被传递给其他版本库的提交试用rebase 命令。否则，这样做可能给日后带来非常麻烦的合并冲突。理顺历史：如果我们在并行式开发的过程中使用merge命令解决了其中的冲突，就会得到一部经历了多次分岔与合并的历史。如果用rebase来代替merge。

合并：所谓合并就是对相关提交图中的分支执行合并操作。合并提交：执行merge命令的结果就是产生一次合并提交。3路合并：Git会在合并时利用提交图找到合并双方最后的共同祖先。然后， Git 将引自该祖先的一个分支上的修改，连同另一分支上所做的修改放在一起。只要这些修改发生在这份源代码的不同之处， Git 就能自动创建相应的合并提交。冲突：对于源代码中 Git无法自动合并(或许是由于同一行被人做了不同的修改)的那个点，我们称这里发生了冲突。内容冲突。

提交图中的分叉：主要是因为修复旧版本 bug 以及并行式开发的需要。分支：上述提交图中出现的那个分叉就叫做分支。该分支会有一个指针，指向该分支 下的最后一次提交。当前活跃分支：我们平常工作所在的就是所谓的当前活跃分支。当新的提交发生时， 该分支指针就会知道被设置到该新提交上。创建分支：我们可以用branch命令来新建分支。checkout: 我们可以用checkout命令切换到另一个分支上。Reflog: git 会记录我们在每次提交中对分支指针所做的所有修改。

对象数据库：所有提交中的文件、目录以及相关的元数据都将被存储在该数据库中。SHA1 散列值：我们可以通过一个SHA1 散列值从对象数据库中捡取相关对象。SHA1 散列值是一种针对文件内容的加密校验值。相同数据只存储一次：内容相同的对象拥有相同的 SHA1 散列值，并且只存储一次。相似的数据会被压缩：对于内容相似的数据， Git 会针对其被修改的部分采取增量存储的方法。Blob对象：文件的内容将会被存储在相应的blob对象中。Tree 对象：目录会被存储在相应的 tree对象中。

项目的版本库通常驻留在其.git目录中。其中包含了以提交形式存储的项目历史。由于Git 是个分布式系统，所以同一个项目通常可能会有多个拥有不同历史的版本库。按照 Git 的设计，我们可以在必要时再将这些历史重新合并起来。提交(通常也被称为版本、修订或修改集): 通过commit命令可以创建一次提交， 一 次提交通常存储了项目的某种确定状态，其中包含了该项目中所有文件的情况。每次提交中都包含了与作者和提交日期相关的元数据。

工作区与版本库：工作区是一个包含.git子目录(内含版本库)中的目录。我们可以用init命令在当前目录中创建版本库。版本提交：一次版本提交通常定义了版本库中所有文件的一个版本，它详细说明了该版本是由何人在何时何地创建的。当然，我们需要用add命令来确定哪些文件将被纳入下一次提交，然后再用commit命令创建新的版本提交。查看信息：通过status命令，我们可以查看哪些文件已被本地修改，以及哪些修改将被纳入下次提交。另外，log命令可用来显示提交历史。diff命令可用来显示两个版本文件之间的差异。

在阅读完本文之后，你现在基本上熟悉了 Git 中的这些基本概念。也就是说， 即使你现在放下了这本书, 你也可以参加与分布式版本控制系统有关的讨论，阐述其中使用散列值的必要性和实用性，介绍 Git中的分支创建与合并操作了。当然，你可能还会有以下疑问。我们应该如何利用这些基本概念来管理项目呢?我们应该如何协调多个版本库呢?我们究竟需要多少分支呢?我们应该如何整合自己的构建服务器呢?对于第一个问题，可以继续阅读下一章内容。