细说 Git 的分支模型
15

file

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

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

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

branches

版本

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

version

分支

通常每个小版本都有一个分支。也就是说分支类似这样: 1.0, 1.11.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 版本。

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

主题分支

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

topic

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

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

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

到此为止

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


Practice makes perfect.

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

译文地址:https://laravel-china.org/topics/10682/t...

本帖已被设为精华帖!
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

  • 请注意单词拼写,以及中英文排版,参考此页
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`, 更多语法请见这里 Markdown 语法
  • 支持表情,使用方法请见 Emoji 自动补全来咯,可用的 Emoji 请见 :metal: :point_right: Emoji 列表 :star: :sparkles:
  • 上传图片, 支持拖拽和剪切板黏贴上传, 格式限制 - jpg, png, gif
  • 发布框支持本地存储功能,会在内容变更时保存,「提交」按钮点击时清空
  请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!