一个成功的 Git 分支模型

云计算 2023-01-04 法医手机阅读

这篇围绕全部源代码的控制工具Git展开。

1. 为什么是Git?

为了深入探讨git和集中式源码版本控制系统的利弊，参见这里。这方面有太多的激烈争论。作为一个开发者，相比其他工具，当前我更喜欢Git。Git的确改变了开发者关于合并与分支的思考方式。在那些经典的CVS/Subversion管理工具的世界中，合并/分支被认为是有些吓人的(“当心合并冲突，它们咬你!”)，而且偶尔你得做些操作解决一些问题。但是使用Git，这些操作都变得极度简单，这些操作被认为是你日常工作流程核心部分之一。例如，在CVS/Subversion这本书中，分支与合并在很后的章节中才被第一次讨论(针对高级用户)。但是在每一本Git书籍中，在第三章就讲到了(基础部分)。由于它的简单性和操作命令的重复性，分支与合并操作变得不再可怕。版本控制工具被认为在分支/合并方面提供操作便利性比什么都重要。关于工具本身，已经讨论的足够多了，下面针对开发模型进行展开。我将要介绍的这个模型不会比任何一套流程内容多，每个团队成员都必须遵守，这样便于管理软件开发过程。

2. 既分散又集中

我们使用的，且与这个分支模型配合的非常好的库，他有一个“真正”的中央仓库。注意，这个库只是被认为是中央仓库(因为Git是一个分布式的版本控制工具，在技术层面没有所谓的中央仓库)。我们将会为这个仓库起名为origin，因为所有的Git用户对这个名字都比较熟悉。

每个开发者从origin拉取和推送代码。除了集中式的推送拉取关系，每个开发者也有可能从别的开发者处拉取代码，形成自己的团队。例如当与两个或者更多的人开发一个大的特性时，或者在将代码推送到origin之前，这种代码管理模式可能有用。在上图中，存在Alice和Bob，Alice和David，Clair 和David三个子团队技术上而言，这只不过意味着Alice定义了一个远程Git仓库，起名为bob，实际上指向Bob的版本库，反之亦然(Bob定义了一个远程Git仓库，起名为alice，实际上指向Alice的版本库)。