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。

SAP Spartacus 的 git flow 和发布流程相关推荐

python做项目管理代码_代码发布项目(三)——python操作git、代码发布流程（服务器管理、项目管理）...
一.python如何操作git 如果你想用python代码操作git需要下载一个模块安装 pip install gitpython 基本使用 #从远处仓库下载代码到本地 importosfrom ...
从一个前端项目实践 Git flow 的流程与参考
Git flow 出自 A successful Git branching model,这里使用了一个前端项目配合本文稿实施了 git flow 并记录流程作出示例和参考,对 hotfix 与持续部 ...
Git Flow分支策略与Azure DevOps相关功能简介
想了很久,还是写这么一篇文章来总结一下有关分支策略和DevOps的一些内容吧.其实,DevOps相关的内容并不是我的工作范围,不过对于敏捷开发.DevOps.项目管理等等这一系列的与开发过程相关的内容 ...
mac中使用Sourcetree的git flow
mac中使用Sourcetree的git flow 前言 1.git flow工作流 1.1 什么是git flow 1.2 git flow上的分支 1.2.1 长期分支 1.2.2 短期分支 1. ...
git flow 工作流
Git flow 工作流介绍 Git Flow 工作流是一个非常成熟的方案,也是非开源项目中最常用到的工作流.它定义了一个围绕项目发布的严格分支模型,通过为代码开发.发布和维护分配独立的分支来让项目的 ...
Git Flow 用法
git flow 工作流程.如下图所示. master 分支 master 分支主要方稳定.随时可上线的版本.这个分支只能从别的分支上合并过来,一般来讲,从develop 上合并,或者从hotfix分 ...
如何正确使用Git Flow 流程
我们已经从SVN 切换到Git很多年了,现在几乎所有的项目都在使用Github管理, 本篇文章讲一下为什么使用Git, 以及如何在团队中正确使用. Git的优点 Git的优点很多,但是这里只列出我认为 ...
Git Flow 工作流程
引言编写的目的 -通过规范化的流程,使得产品.开发与测试等各个部门更高效的协同工作. -通过规范化的流程使得产品高效稳定运行. 背景在多组员,多项目等环境进行协同工作时,如果没有统一规范.统一流程 ...
SAP Spartacus checkout 流程使用 url 粘贴直接跳转到 delivery mode不能打开页面的原因
http://localhost:4200/electronics-spa/en/USD/checkout/delivery-mode 没有任何错误消息,白屏: 能看到向 checkoutDelive ...

SAP Spartacus 的 git flow 和发布流程