一个成功的git分支模型（翻译）

本文翻译自A successful Git branching model by Vincent Driessen

在这篇文章中，我提出了一个开发模型。大约一年前我介绍过我所有的项目（包括工作上和私人的），经过一年的时间，这个模型已经被证明是非常成功的。我一直想把这些写下来，但直到现在我才有时间来做这些。这篇文章中不会谈论任何项目的细节，只包含对分支策略和发布管理的探讨。

它所着重围绕的Git是我们所有源代码的版本控制工具。

为什么是 git ？

在网上我们能看到很多有关于 Git 与集中式代码控制系统之间孰优孰劣的深入讨论，大量的争论在这个问题上产生。然而作为一个开发者，我喜欢Git胜过其他所有代码管理工具。Git 真正地改变了开发者对于合并（merge）还有分支（branch）的理解。就我最初接触的 CVS/Subversion 而言，合并/分支 总是被看做一件很恐怖的事情（“一定要小心合并冲突，出问题了他们会咬人的！”）或每隔一段时间做的事。

但是 Git 不一样，在 Git 中这些操作非常简洁明了，而且被认为是日常工作流程的核心部分之一。例如，在 CVS/Subversion 的书籍中，分支和合并的内容会在后面的章节讨论（针对高级用户）。然而在每本 Git 教程中，这部分内容已经涵盖在前三章（基础）中了。

由于它的简单性和复用性，分支和合并再也不是一件值得惧怕的事情。版本控制工具就应该将有助于分支/合并放在首位，它比任何其他事情都重要。

了解了工具之后，让我们把目光转向开发模型。我在这里想介绍的模型实质上不过是每个团队成员都必须遵循的一组程序，目的是管理软件的开发过程。

分散但集中

我们使用和分支模型运作良好的资源库设置，它有一个“真实的“中心库。值得注意的是，这个库仅仅被看做是中心库（自从 Git 被设计为分布式代码管理系统，技术层面就不存在中心库这个概念）。我们将把这个库称为 origin ，这个名称对于所有 Git 用户来说都很熟悉。

每个开发者都从 origin 上发布（push）和同步（pull）。但是除了集中地 push-pull 关系，每个开发者也可能从其他团队成员或子团队中同步改变的代码。举个例子，这可能在两个或多个开发者共同开发一个新的分支的时候有用。在上图中，包含 Alice 和 Bob，Alice 和 David，Clair 和 David 三个子团队。

从技术上而言，这不过意味着 Alice 定义了一个叫做 Bob 的远程分支，指向 Bob 的仓库，反之亦然。

主要的分支

最为核心的，这个开发模型受到了目前其他模型的极大鼓舞。中心库在无限的生命周期中始终包含两个主要的分支：

• master
• develop

每一个 Git 的使用者都应该熟悉本地主分支（master branch at origin）。它和主分支是并行的，其他的分支叫做开发分支（develop）。

我们认为 origin/master 是主要分支是由于 Head 标记的源码总是反应着生产准备状态。

我们认为 origin/develop 也是主要的分支是由于 HEAD 标记反应着为下一个版本最新提交的开发修改。有些人把这个叫做集成分支。

当开发分支中的源码趋于稳定并准备发布时，所有的修改都应该和主分支合并，并且以发布版本号进行标记。这里应该如何做将在后面进一步讨论。

因此，每当有修改要与主分支合并，定义上这都是一个新的版本。我们往往对此非常严格。理论上，每当主分支上有提交时，我们就使用一个 Git 钩子脚本（Git hook script）来完成自动化构建，把软件转出到生产服务器上。