关于git:SAP-Spartacus-的-git-flow-和发布流程

Git Flow and Release Process

Library Version Compatibility

Spartacus 我的项目由一组库组成。 为了更容易晓得哪个版本的库与另一个版本兼容,库版本在所有包之间同步。 这意味着当咱们要公布 1.5.0 版本时,咱们会公布此版本下的所有库,即便某些库自上一版本以来没有任何更改。 这样做时,咱们能够应用单个版本号来援用任何给定版本的整个 Spartacus 库集。

这也意味着您能够确信,如果您装置所有具备雷同版本的软件包,那么所有都将失常工作。 不同版本的库能够很好地协同工作,但咱们不会测试这些配置,也不能保障正确的行为。

version support

对于版本控制,咱们遵循语义版本控制,也称为 SemVer。 除了稳固版本,Spartacus 还生产 next 和 rc 版本。

咱们对版本的假如如下:

  • Stable 版本是通过良好测试的 Spartacus 版本(包含社区测试),并且只会修补谬误。这些版本在 npm 上的最新标签下可用。
  • 当 Spartacus 团队实现该版本所有新性能的开发后,就会公布一个 rc 版本,这意味着性能和公共 API 不会有任何重大变动。社区能够平安地开始测试 rc 版本中的性能。 rc 版本可能蕴含一些谬误,这些谬误将在稳固版本公布之前修复。当没有更多谬误并且社区进行报告该版本的问题时,咱们会持续制作稳固版本。
  • 当 Spartacus 团队实现特定性能时,将公布一个 next 版本。这容许社区立刻开始测试该性能。这些 next 版本可能蕴含很多谬误,性能和公共 API 可能仍会发生变化。如果您想尽快测试新性能,这是适宜您的版本。下一个版本在 npm 上的 next 标签下可用。

留神:强烈建议您不要在生产设置中应用 next 版本。这是因为从next 版本升级可能比从一个稳固版本升级到另一个要艰难得多。

Support Policy

始终反对至多一个稳固或 rc 版本。

一旦版本 x.y 公布,它将被踊跃保护,直到版本 x.z 的新稳定版或 rc 公布。 届时,版本 x.z 将成为踊跃保护的版本,下一个版本的工作将开始。

例如,假如咱们刚刚公布了 1.5.0-rc.0 版本。 从那时起,将踊跃保护 1.5.x 版本,直到咱们公布 1.6.0-rc.0。 一旦 1.6.0-rc.0 版本公布,咱们就会将被动反对切换到 1.6.x 版本。

留神:对于重要的平安问题或要害的谬误修复,可能会有针对不再踊跃保护的版本的附加补丁。

Git Flow

Spartacus 我的项目中的流程围绕后面局部中形容的版本反对构建。

develop 分支是默认分支,用于新版本开发,包含主要和次要版本。 所有性能和谬误修复都合并到这个分支。

还有一个 maintenance 分支,它随着新的稳定版或 rc 版本而变动,用于补丁版本。 只有谬误修复合并到 maintenance 分支。

一旦咱们公布了 1.4.0-rc.0 版本,release/1.4.x 分支将被视为保护分支。 当咱们公布 1.5.0-rc.0 版本时,则 release/1.5.x 分支成为保护分支,依此类推。

其余分支约定:

  • feature/GH-xxxx 分支用于简略的性能和谬误修复
  • epic/epic-name 分支用于大特色(称为 epics)
  • release/1.4.0-rc.0 分支用于特定的公布(你能够将它们与保护分支辨别开来,因为蕴含残缺的版本号)

Flow for Epic Development

  • 从 develop 分支创立一个新的 epic/epic-name分支。
  • 从epic/epic-name 为epic 子工作创立分支,并将它们合并回 epic/epic-name 分支。
  • 不断地应用来自 develop 分支的更改更新您的 epic/epic-name 分支(它将帮忙您治理抵触)。
  • 当 epic 实现时,创立一个 PR 并将 epic/epic-name 分支合并到 develop 分支。

Flow for Smaller Features

  • 从 develop 分支创立一个新的 feature /GH-xxxx 分支。
  • 开发您的性能。
  • 实现后,创立一个 PR 并将 feature/GH-xxxx 分支合并到 develop 分支。

谬误修复流程

以下是处理错误修复的步骤:

  • 从开发分支创立一个新的 feature/GH-xxxx 分支。
  • 修复谬误。
  • 创立 PR 并将 feature/GH-xxxx 分支合并到 develop 分支。
  • 如果此修复实用于积极支持的版本,请从 maintenance 分支创立一个新的 feature/GH-xxxx-maintenance 分支。
  • Cherry pick the commit with the fix from the develop branch.
  • 创立 PR 并将 feature/GH-xxxx-maintenance 合并到 maintenance 分支中。

Terminology

以下是咱们目前应用的可能会产生误导的术语:

“feature freeze” 形容了咱们实现了新的主要或次要版本的所有性能的那一刻(这意味着咱们心愿很快公布一个 rc,但仍须要修复一些谬误)。

“code freeze” 形容了咱们进行提交代码的那一刻(只管这在咱们的流程中不是必须的,因为咱们总是能够切断公布或保护分支并持续提交)。

以下概念可用于替换这些术语:

咱们能够创立一个新的保护分支并公布一个新的 rc。 第一个 RC 可能有问题,因为 rc 版本可能蕴含谬误是公认的。

咱们能够创立一个新的 release 分支,而不是解冻代码。 咱们永远不须要阻塞次要的开发或保护分支(咱们不须要用这些细节来打搅开发人员,因为咱们的流程反对在这些分支上并发工作并公布另一个版本)。

term:保护分支,个性分支

maintenance 分支是须要合并到release/xxx的货色

示例:你合并了一些货色来开发,但它须要在 4.0.1 中或者也须要向后移植到另一个旧的公布分支,而后你须要创立一个 PR 来将它合并到 release/4.0.x 。

通常,新性能保护分支最终是 feature/GH-xxx-maintenance 并将合并到 release/xxx 而不是 develop。

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据