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。