细说 Git 的分支模型

自 nvie 发布的初代 一个成功的的 Git 分支模型 以来，已经有许多人在尝试简化它。虽然它是一个很稳健的分支策略，但是终将产生大量垃圾分支。

这篇文章旨在记录 PHP 社区的一个子集 (也可能其他社区) 已经在使用的一直常规策略，同时这个与 语义版本控制 和 composer 协作很好。

注意：该模型适用于 OSS 项目。对于产品， 我推荐 就像这个 这种的。

版本

根据语义化版本控制的定义方式，版本采用 MAJOR.MINOR.PATCH 的格式。

分支

通常每个小版本都有一个分支。也就是说分支类似这样： 1.0， 1.1，1.2， 2.0， 2.1， 2.2， 等等。『最新』版本由 master 分支表示。这是通常的惯例。

但是『最新』就意味着非此即彼。一种是未发布的开发版本。例如 1.1-dev 终将成为 v1.1.0 。而另外一种就是， 已经存在 1.1 的发布版本了，它将是 下一个 版本的演进， 例如 v1.1.1。

标签

版本由标签标识。标签描述了补丁版本，且指向了小版本的提交。如 v1.0.0 标签指向了 1.0 分支的提交。

不同于 nvie 模型，由于从标签可推断版本信息，所以没有专门的版本分支。

Bug 修复

很多情况下，将会同时有不止一个分支处于活跃状态下。Bug 修复应当以最后的支持分支为目标。例如，如果 1.0 分支不再维护了，但是 1.1 和 1.2 都是活跃状态，Bug 修复分支应当基于 1.1。

因为 1.2 是 1.1 的下游分支，它同样也会得到这些 Bug 修复。只需定期将 1.1 合并进 1.2 分支就行。

功能

根据语义化版本控制精神，新功能应产生新的小版本。如果最新发布版为 v1.0.5，那么 master 分支应标识为 1.1。新功能应合并入 master 分支。一旦 v1.1.0 发布， 1.1 应当从 master 上分出来，且 master应该变成 1.2 版本。

对于较小的项目，这个规则可适当宽松，新功能可以合并到已有版本的分支中。但请记住，它会使用户难以跟踪哪个版本引入了特定的功能。

主题分支

一个工作流中的贡献者通常都是基于主题分支进行工作的。 他们并不直接想特定的版本分支进行提交，取而代之的是，定制一个单独的功能或错误修复分支，可以在这种分支上独立进行开发。完成之后，这些主题分支就会被合并进版本分支当中。

如果改动较大，跨度涉及多个提交，它还可以跟踪何时合并了什么内容，并且可以按需一次性恢复。

更重要的是，它允许独立原型的新功能，而且无需提交这些更改。

通常主题分支非常短暂，合并后会被丢弃。

到此为止

这篇文章记录了我们中的许多人在自己项目中的使用过程。 如果您有任何要添加的内容，请在评论中分享。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

原文地址：https://igor.io/2013/10/21/git-branching...

译文地址：https://learnku.com/devtools/t/10682/the...